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" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
