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

Mon Jul 13 02:56:20 UTC 2015

ForgeRock also has an UMA implementation. Would it make sense to use one as
the RS and the other as the AS and then write a client that would report
Alice's age (iff Bob is allowed to ask)?

Adrian

On Sunday, July 12, 2015, Aaron Seib <aaron.seib at nate-trust.org> wrote:

> Justin given your experience do you have a recommendation?
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces at lists.openid.net');>]
> *On Behalf Of *Justin Richer
> *Sent:* Sunday, July 12, 2015 10:35 PM
> *To:* Adrian Gropper
> *Cc:* openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>
> *Subject:* Re: [Openid-specs-heart] Flip the question of “Vanilla" OAuth
> vs. UMA
>
>
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
> 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/
>
>
>
>
>

-- 
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/5eb622e8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3141 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150712/5eb622e8/attachment-0001.jpg>