>
> Yes, I would like to solve the problem that was previously known as OBO. That
> is, third party requests that use the mechaisms provided by held-identity.
>
> I'll note that OBO is a term that isn't necessary because we already had
> adequate labels in the GEOPRIV model.
OK, I can accept calling this is a limited use case third party model.
>
> That's right. I'm saying that we don't need to justify our use case in
> privacy terms. Not any further than we have already.
You may get other comments around end-user knowledge of location
dissemination/rules, etc.
>
>> Before we can agree to the above, we have to agree that HELD identity
>> extensions is strictly for the use-case described (further) above,
>> third-party/OBO (we need to pick one term), and can not be used by a
>> target discovering it's own location from a Rulemaker pov.
>
> We did agree. It's not LCP. It's someone requesting the location of someone
> else.
Then state this is not addressing a target discovering it's location
use-case in the draft.
I believe the draft takes too many liberties with "LCP Policy". That policy
still falls under the Rulemaker and is not a given.
Just to be clear, the draft is asking for the functional equivalent of
pres:identifier-du_jour@lis.example.com, correct? Knowing this allows me to
compare the security/privacy attributes.
-Marc-
>
> --Martin
>
>
> ------------------------------------------------------------------------------
> ------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------
> ------------------
> [mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
