The flow is not SAML-specific. EHL
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Prateek Mishra > Sent: Thursday, May 13, 2010 10:15 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow > > SAML 2.0 assertions can represent a variety (very large) of relationships > between the presenter, issuer, subject, means of confirmation and so on > and so forth. > So representing multiple identities - i am server foo but I am acting for joe > - is > not very difficult. > > We can profile these versus adding parameters to the flows. > > - prateek > > > > Our plan is to treat SAML assertions passed over the assertion flow as > > bearer assertions, so I believe we have everything we need contained > > within the assertion (issuer + audience + signature). That being > > said, if we want this to be an extensible flow, not all assertion > > formats will be so transparent. > > > > I think this is a reasonable suggestion, as long as the > > clientid/secret are entirely optional. Not in support of a second > > User Assertion Flow. > > > > -cmort > > > > > > On 5/13/10 3:38 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> > wrote: > > > > In my perception, we reached consensus in the thread "Autonomous > > clients > > and resource owners (editorial)" that the assertion flow should > > support > > clients acting on behalf of users, not only autonomous clients. > > > > The specification currently states "This flow is suitable when the > > client is acting autonomously or on behalf of the end-user (based > > on the > > content of the assertion used).", which is fine with me. > > > > Im struggling to understand how the flow handles the two required > > identities, the client and the end-user. I basically see two options: > > > > 1) the assertion attests both identities. I'm not aware of any > > identity > > framework attesting two identities in a single assertion. > > > > 2) If we assume the assertion attests the end-user's identity only, > > there is the need for additional parameters used to authenticate the > > client. From my point of view, the situation is similar to the > > "Username > > and Password Flow". There, the specification defines two > > credential sets > > (username/password and client_id/client_secret) two prove both > > identities. > > > > Therefore, I would propose to add optional client_id/client_secret > > parameters (or an Authorization header) to pass the client credentials > > to the assertion flow if the assertion contains the end-user identity. > > Alternatively, one could add another flow to the spec, probably called > > "User Assertion Flow". > > > > Any thoughts? > > > > regards, > > Torsten. > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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
