On Wed, Aug 4, 2010 at 3:00 PM, Prateek Mishra <prateek.mis...@oracle.com> wrote: > Thanks for the clarification (Paul, Chuck and Brian), re-reading the most > recent draft makes the use-case pretty clear, not sure how I came up with my > own personal use-case in this instance (not enough coffee probably...)
If you think there's anything that could be added or removed to make it more clear, please let me know and I'll try and incorporate it. > To me it seems that this is an instance of a SAML --> OAuth token mapping > service, which seems a pretty useful service. One question is whether there > needs to be a general framework for its use; I guess this was the substance > of interaction between Brian and Tony earlier in the thread. I guess I need > to research the issue some more before joining that discussion. I'm not sure there was that much substance to Tony and I's interaction - we were just discussing the merits of allowing for more than one assertion in this profile. I guess that does generalize it somewhat but I don't know that it makes it a 'general framework its use.' Honestly, I'm not even sure what that would involve. To some extent, the assertion grant type in OAuth is the general framework for exchanging a token/assertion for a OAuth access token. And, as you point out, this profile is an instance of that that does SAML --> OAuth. Do you think there needs to be something more generalized somewhere? > Here is a simpler question: is there a requirement that the Client/IdP > authenticate to the Authorization server when presenting the SAML bearer > token? I didnt see it in the current draft - or is that taken care of in the > base OAuth 2.0 protocol? Client authentication is in the core OAuth spec but it is optional. So I'd imagine it will end up as a policy decision at deployment time. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
