Hi,

Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security
token service (STS) where they can obtain assertion grants and the AS
trusts the STS to issue such assertions. In that kind of scenario, the
identity of the client can be considered unimportant - what's important
is that the AS trusts the STS and in turn the STS trusted the client
enough to issues it a suitable assertion.

What confuses me still is this: given a grant (whatever grant it is) AS issues a token which is associated with a given client somehow.

When a registered client uses JWT or SAML assertion to authenticate it is all clear (I can imagine the client logs on to STS, gets the assertion and authenticates with it to AS).

Now if we have an unregistered client using an assertion grant, how do we associate a token with this unregistered client, the text seems to imply that the assertion grant does not identify this unregistered client either, so it is not clear how this client can use the token afterwards, even though AS can validate with STS/etc that the grant is valid.

Is the idea that the registration happens after the unregistered client has exchanged an assertion grant for a token ?

Sorry, I know I'm missing something  obvious here...

Thanks, Sergey




On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:

    Hi

    I'm reviewing the way client authentication is expected to be done
    when either SAML or JWT bearer assertion is used as a grant [1]
    which corresponds to the case described in [2].

    [1] says: "Authentication of the client is optional...".

    Can someone please clarify how it can be optional given that in this
    case a subject of the assertion does not identify a client ? Is it
    about supporting unregistered clients which have managed to obtain
    somehow the assertion grants ?

    Thanks, Sergey

    [1]
    http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1
    <http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-4.1>
    [2]
    http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3
    <http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3>

    _________________________________________________
    OAuth mailing list
    OAuth@ietf.org <mailto:OAuth@ietf.org>
    https://www.ietf.org/mailman/__listinfo/oauth
    <https://www.ietf.org/mailman/listinfo/oauth>





_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to