(Routing this to Kitten WG)
I don't have much of a preference here, on the one hand I think a plaintext
hint is very reasonable, on the other I suspect people will be tempted to use
it for more than that which would be bad. In the HTTP space it's easy for
anyone using OAuth to put a plaintext cookie with the same function, but I
dont' really want to try to bring a cookie carrying mechanism into the draft.
-bill
BCC: OAuth WG
________________________________
From: Ryan Troll <rtr...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
