Re: [Geopriv] Pawn Ticket URLs

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Sat Jul 29 2006 - 10:54:29 EDT

Hi Randy,

I read the draft some time back when you pointed me to it. I had
difficulties to understand because the document lacks a high-level
overview.

The document says:
"A URLAUTH-authorized URL conveys authorization (not authentication) to
the data addressed by that URL."

 From a conceptual point of view this document defines something that is
similar to requesting and conveying a SAML assertion in a data URI. It
uses its own format and only a limited set of parameters.

I think that there is no additional gain in security or functionality
for the topic being discussed here.

Ciao
Hannes

Randall Gellens wrote:
>> A while back there was some brief discussion in geopriv about using
>> "pawn ticket" URIs for location information. That is, URLAUTH from
>> RFC 4467, which is a URL that has been signed by the server and can be
>> used by the holder to gain access to the information, subject to
>> expiration time and/or role restrictions. Role restrictions limit the
>> URL to being used by an entity that is known to the location server as
>> performing a specified role. Additionally, RFC 4467 allows all
>> currently-issued URLs to be revoked by changing the key.
>>
>> I wonder if there is any value in this?
>
>
> There might be some impact on the policy document to using "pawn ticket"
> URLs. A holder of such a URL could be authenticated during the
> dereference, or not (to avoid revealing requester identity even to the
> location server). Using such a URL when not authenticated is not the
> same as an unauthenticated disclosure, though.
>
> If the keys are associated with an identity (possibly unlinkable), and
> if the rule maker can create multiple identities, each with its on key,
> then the specific identity is a condition.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 29 Jul 2006 16:54:29 +0200

This archive was generated by hypermail 2.1.8 : Sat Jul 29 2006 - 11:09:52 EDT