[Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA

[Debbie Bucci]

It does make sense and  I can at least *see* your perspective.   Not quite
covinced the gap are that wide and/or that adjust couldn't be made as we
move to pilot implementations.

Side by side ... is closer.
On Jul 12, 2015 8:05 PM, "Justin Richer" <jricher at mit.edu> wrote:

>  An OIDC client and an OAuth client are after different things, though.
> OIDC is an authentication and identity protocol, OAuth is neither. An OIDC
> client is going to specifically be looking for the id_token and
> specifically asking for the 'openid' scope in order to get it. The
> mechanics on the wire, on the other hand, are nearly identical between the
> two, since an OIDC transaction really is just an OAuth transaction with a
> couple of special inputs (the 'openid' scope) and outputs (the 'id_token'
> in the token response). You can pretty easily build an OIDC client on top
> of an OAuth client.
>
> However, it's just not the same with UMA and OAuth (or OIDC). Think of it
> in terms of software: if I have an UMA client and I try to make it talk to
> a plain OAuth RS, it's going to have no idea what to do. Same goes the
> other way around. It's not a matter of "just a couple more redirects",
> since those redirects define a completely different protocol and require
> different code paths. If you're very, very careful you can have them side
> by side, and that's the best that we can work for in HEART in my opinion.
> But that doesn't mean we should try to figure out what both UMA and OAuth
> look like for every single use case. Especially when considering you can do
> AS introduction to both the client and RS outside of UMA (mostly -- we'll
> need to paste over some protocol gaps but it's all doable).
>
> And finally, in UMA 1.0, it's the RS that actually needs to know which
> scopes to give for a transaction. The user and client have no way of
> telling the RS which scopes they want, the RS just has to guess correctly
> and attach those to a ticket. The client in UMA is supposed to just take
> the ticket and let the AS figure out what to do with it.
>
> Hope this makes sense,
>  -- Justin
>
> On 7/12/2015 7:57 PM, Debbie Bucci wrote:
>
>   >>> Unfortunately, there's no "is_alice" flag in the protocol stack
> that we can count on.
>
>  Maybe there should be.   How does a client know its an OIDC client ....
> the presence of the id_token?   An OAUTH client needs direct the resource
> owner (assumed Alice?)  to get a token on its behalf by somehow knowing
> what the authorization endpoint is  ... typically done via the RO user
> agent and the redirect URI is/are given.  In the delegated flow ... Alice
> is not around ... could that be a trigger?   Bob (delegate) will need to
> have a pre arranged relationship with the authorization server in some way
> or manner.
>
>
> >>>An UMA client needs to be able to be pointed to an AS, take in a ticket
> (as a JSON value, regardless of what encoding the API it's speaking to
> uses), talk to the "requesting party" endpoint to trade the ticket for a
> token, and then it needs to be able to gather the claims that the AS gives
> it hints for. As Eve keeps pointing out, those claims could be absolutely
> anything, fulfilled by the client or by someone else or just because it's
> Tuesday, so the client is really going to need to be written to a very
> specific profile of UMA for it to have any chance of doing something
> useful. Then it needs to come back with the ticket, again, and try to get a
> token, potentially repeating the claims gathering cycle if it guessed wrong
> on the last step.
>
>  I believe you just [primarily] explained the *on the wire* on the ATT
> flow (thank you!).
>  Following the flow ... it seems the burden is on the Requesting party to
> understand what claims the AS hints for - not the client.
>
>  I may be naive but does a client really know how many redirects occurs
> until its has an access token?
>
>
>
>
>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150712/76c9d73f/attachment-0001.html>