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

Mon Jul 13 02:34:37 UTC 2015

MITREid Connect contains a functional UMA server component, which is even past what we demoed at HIMSS earlier this year. This is slated to be released in version 1.2, which just had its first Release Candidate last week. (A release candidate means the full 1.2 release is relatively imminent.) The only gap (and it’s a major one) is that Bob currently needs to have an account on the server to get the AAT. Ideally this would be filtered through an external login, allowing Bob to do a plain OAuth transaction to get the AAT to his client, but at the moment that’s not possible in the MITREid Codebase. I’m hoping that it’s a matter of configuration more than anything, but I haven’t done the deep investigation of that yet and it’s going to require some pretty hefty Spring Security voodoo. Apart from that, everything else works as far as I know, but it’s only been tested against custom-coded clients that were pointing only to MITREid.

It’s from hands-on coding this server and interacting with the developers of the clients and protected resources during the demo that I’m speaking from with regard to the differences between OAuth and UMA on the wire as a protocol. They really aren’t the same. UMA uses OAuth, but it isn’t “OAuth with a couple extra things”. This is in contrast to OIDC, which really is “OAuth with a couple extra things” since the transactions are fundamentally the same.

 — Justin

> On Jul 12, 2015, at 10:12 PM, Adrian Gropper <agropper at healthurl.com> wrote:
> 
> Justin,
> 
> How far long is the UMA addition to MITREid Connect right now? Would it make sense for us to design the absolutely simplest possible demo of UMA around the most trivial use case we can think of as a way of getting everyone on the same page?
> 
> I'm volunteering to help with the design, documentation, and management of such a demo. I might code C or Python but I doubt that would help. 
> 
> Adrian
> 
> On Sun, Jul 12, 2015 at 8:48 PM, Debbie Bucci <debbucci at gmail.com <mailto:debbucci at gmail.com>> wrote:
> 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 <mailto: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?
>> 
>> 
>> 
>>  
>>  
>> 
> 
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <mailto:Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> 
> 
> 
> 
> -- 
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150712/55f2fc40/attachment-0001.html>