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

[Justin Richer]

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/b7bdc8db/attachment.html>