[Fwd: [kitten] Fw: [OAUTH-WG] SASL / OAuth Binding Request: User Field]

aligns it somewhat with webid, the value in having transparent user 
identifiers within the protocol ->

-------- Original Message --------
Subject: [kitten] Fw: [OAUTH-WG] SASL / OAuth Binding Request: User Field
Date: Mon, 16 Jul 2012 16:22:42 -0700 (PDT)
From: William Mills <wmills@yahoo-inc.com>
Reply-To: William Mills <wmills@yahoo-inc.com>
To: kitten@ietf.org <kitten@ietf.org>
References: 
<CAPe4Cjr=XrCyubv2tihuRaO0tfidQToJ3_bMMpmxcZPsXDEQpg@mail.gmail.com> 
<1342480265.22646.YahooMailNeo@web31807.mail.mud.yahoo.com>

(bringing this to the Kitten list where it probably should be, might get 
a dup of a different message too)


I'm fine with Ryan's desire to bring back the "user" element into the 
SASL message.  In an HTTP environment the server would probably 
accomplish this with a cookie, I don't want to make a general cookie 
mechanism, but I'm OK with requiring a username hint in the SASL message 
itself.  The only danger I think is that developers will use it for more 
than just a hint, which isn't to huge a deal.

Any objection to this?


-bill



----- Forwarded Message -----
From: Ryan Troll <rtroll@googlers.com>
>To: oauth@ietf.org 
>Sent: Monday, July 16, 2012 11:46 AM
>Subject: [OAUTH-WG] SASL / OAuth Binding Request: User Field
> 
>
>I'd like to discuss the possibility of adding a "user" field to the SASL/OAuth request.  This is based on draft-ietf-kitten-sasl-oauth-00.txt.
>
>
>Background
>The contents of this field may be used by the resource provider as a hint to aid in request routing, and/or data location, without the need for decrypting the provided access token.  The contents of the user field is not used to grant access of any kind.
>
>
>
>
>Proposed Addition
>The text of this addition could look something like this:
>
>
>Section 3.1 addition / update:
>
>
>user:  Contains the user ID of the user being authorized
>>
>>In authorization schemes that use signatures, the client MUST send host, port number and user key/values, and the server MUST fail authorization requests requiring signatures that do not have host, port, and user values.
>
>
>Section 3.2 addition:
>
>
>If the user field is present, the ID in the user field must match the ID obtained from the credential for the request to succeed.
>
>
>
>
>Rationale for Presence of User Field in the Request
>This data is not required by all resource providers, and as such could be a provider-specific requirement, placed (for example) in the query string.  By documenting the user field, we encourage resource providers that do require it to find it in the same location - encouraging inter-operability.
>
>
>The user identity could be determined via the access token, rather than requiring it in the request.  However, using the access token to determine the identity can result in the resource provider decoding the token multiple times, or making multiple requests to the access provider.  By pulling this attribute out into the protocol, we may be able to simplify the resource provider work required when moving to OAuth.
>
>
>
>
>Rationale for Location of User Field
>This data could be transmitted as part of the path, or a query string parameter, or in the post body.  This approach, using a header, was proposed as there are currently no path, query string, or post fields defined.  Those three locations remain untouched by this proposal.
>
>
>
>
>Comments?
>-R
>
>
>
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

Received on Monday, 16 July 2012 23:26:27 UTC