Chuck,
This is a good draft. Real progress. I wish we had this draft before the WG
spent so much time in IETF-Prague arguing about the assertions text.
Just a short question. Section 5.1 states that the principal identity SHOULD
be the client_id (for the OAuth client):
Principal A unique identifier for the subject of the assertion.
When using assertions for client authentication, the Principal
SHOULD be the client_id of the OAuth client. When using
assertions as an authorization grant, the Principal MUST identify
an authorized accessor for whom the access token is being
requested (typically the resource owner, or an authorized
delegate).
Why is this a "SHOULD"? (I would think this is a "MUST).
In Section 6.1 "The Principal MUST identify an authorized accessor". In Section
6.3 "The Principal MUST identify an authorized accessor...".
PS. More broadly, I'm thinking not only of a model where the OAuth-client gets
an assertion from the STS/IdP server, but also of a situation in where the
human-user (resource owner) specifically names the Subject (the OAuth Client)
in a multi-hop delegation case.
More questions later.
Thanks.
/thomas/
__________________________
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Chuck Mortimore
> Sent: Saturday, June 18, 2011 3:42 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] New Assertion Draft for review
>
> A number of us in the community have been working on a general model
> for the use of Assertions in OAuth2 for both client authentication, as
> well as authorization grants. We've reached general consensus on a doc
> that I've published as a draft:
>
> http://www.ietf.org/id/draft-mortimore-oauth-assertions-00.txt
>
> Feedback and discussion welcome!
>
> Thanks
>
> -cmort
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
