On Aug 10, 2015, at 5:57 PM, Eve Maler <eve@xmlgrrl.com> wrote:

Thanks for sending this, and sorry again for not having seen it in time. The danger of a) filtering email directly into a folder and b) getting a lot of email… Yikes.

I actually have a V1.0 swimlane along with the swimlane I sent out, so if you respond with answers to my questions below, I can correct the new one and send out both for comparison. I found the exercise of doing endpoint-specific swimlanes valuable.

This looks pretty close. Some comments below.

On 8 Aug 2015, at 7:28 PM, Justin Richer <jricher@mit.edu> wrote:

Since I wasn't able to make the call, let me try to lay it out end to end for people to see what I'm talking about:

0) Alice sets up a relationship between RS and AS, just like UMA says to do today. Done, no big deal.

1) Bob tells his client to access a resource, the resource says "no", and points bob's client at the AS along with a ticket (which should be passed in the response header, but that's another issue)
2) Bob's client registers with the AS (dynamically on its own, or by pestering bob to email an admin and do it the hard way, whatever).
3) Bob's client then sends a request to the token endpoint using a *new* OAuth grant type, let's call it grant_type=uma_authorization (in reality it's a URI but work with me here). The ticket is passed as another parameter, since it's just a simple string.
4) The combination of the client's own credentials and the ticket are sufficient to start the token request process for Bob's client.
5) As this is a call to the token endpoint, the client can even ask for a specific set of scopes, just like it could with a refresh token or other backchannel grant types.
6) The AS decides that it needs to know more about Bob before it can issue a token, so it responds with "need_info" to the client.
Bob's client then figures out a way to get those claims to the AS, either by casting a spell and getting a magical assertion that can ignore audience restrictions and other security and sanity measures (which people have pointed out that they're already doing in practice) or by having

(Hmm, no need for the ad hominem... The use cases I’m involved in do no such thing. And as I’ve pointed out, other assertion languages besides OIDC’s somehow manage to be flexible enough to be used in new protocols.)

Bob interactively present himself to the claims gathering endpoint.

There is no ad hominem attack present in my comment, except against those who would willingly ignore audience restrictions on assertions that are designed to have them (both SAML and OIDC come to mind here). There are some very limited use cases where this can be optimized (like the AS being the issuer of the assertion, or the AS being audience of an assertion granted to the client by a third party specifically to carry to the AS). What I’m trying to say is that, in my opinion, these should be very carefully cordoned off by the spec as special optimization cases. Otherwise, you run a very real risk of developers slinging around bearer assertions that they’re not meant to be publishing, and around parsing assertions not meant for them and taking them as good. Both of these kinds of mistakes have been well documented in the wild, often to horrible effect.

7) If the client passes an assertion, it can do so to the token endpoint in a new parameter, like say uma_assertion=ejy...foo. Basically "oh let me try that again but with more stuff this time”.

Are you saying the client is identifying itself through claims, or Bob? On the last call, it was discussed that Bob needs an opportunity to consent to the AS/C authorization process, as we have now. You’ve got consent below, but if the client has already started pushing Bob’s claims, it’s too late. Or am I missing something? Needs discussion.

I’m simply saying that the current direct assertion presentation mechanism, with all of its flaws as discussed above, is still fully supported by an OAuth extension grant as opposed to a custom endpoint. With that, you can use it to pass whatever claims you like through it. For example: Does the client have an assertion to identify its deployment organization in a way that’s not communicated through the client_id? Sure, send it here! Did you get Bob’s identity assertion directly from this AS? Sure, send it!


8) If the client sends Bob to the interactive claims gathering endpoint, Bob can log in to a local account, or use a federated login (like the OIDC model we used in PoF), or provide some shared secret that Alice emailed to him, or squint really, really hard at his screen -- whatever the claims require. The AS is still free to have this be whatever it wants, importantly including capturing Bob's consent to use the client (since it's identified itself here). [ Also note that in the alice-to-alice case, the AS can basically re-purpose its authorization endpoint after Alice logs in and this all collapses to vanilla OAuth. ]

Not sure I understand. Alice logs in to the claims-gathering endpoint and then gets sent to the authz endpoint? or the one endpoint equals the other? or something else?

I haven’t tried to actually build this out yet, but this would be another optimization step that the AS could undertake if it recognizes Alice logging in to share with herself. Basically, instead of collecting claims about Alice herself, because the AS is already pretty sure that Alice is Alice, it can instead get Alice’s consent a-la a more traditional OAuth style authorization screen. Whether this happens through the authorization endpoint or the claims gathering endpoint kinda comes out in the wash, but I am assuming it’s the latter owing to the different kind of response required. Either way, the interactivity is a good place to gather Bob’s consent.


9) With the claims probably in place, the client can try again at the token endpoint with the same ticket.
10) If the claims aren't good enough, repeat 6-9 ad nauseum until someone guesses the right set of claims (but that's another issue). If they're good enough, issue an OAuth token using the standard OAuth token endpoint response structure. This includes expiration, scopes, and other hints to the client. It can even include a refresh token, ID token, or other extension stuff. This also allows the RPT to be a PoP token without UMA

Since the current MTI-defined RPT structure includes permissions for multiple resource sets, each has its own expiration, and the AS has the opportunity to cache claims that it learns about the RqP independently of the policy needs of any one RS, individual permission time-to-live can potentially be managed completely independently. We’ve discussed in the past whether it made sense to have a refresh token, and decided it didn’t. It’s worth examining just how many normal OAuth token constructs can be made to fit UMA, but if not all do, what’s the right answer?

If the RPT can turn into a regular access token, which it by all colors already is and our implementation mints and stores it as one, then you can start to attach other normal access token kinds of things to it. A refresh token is pretty helpful if you want the RPT to expire in a shorter timeframe than the grant that was used to mint it. As a (big) added bonus: your clients don’t have to do anything special to handle it: it’s just another access token.

Does a PoP token automatically mean the “right thing” for UMA? (It’s something I’ve been wondering for a long time, actually.)

Also, as was already discussed, we have to get the privacy implications right around token issuance. It’s different in a use case that involves a “Bob” than one that only involves an “Alice”.

having to say anything about whether or not it is, since token_type is a required response parameter and UMA can now inherit new token definitions.

PoP will make a lot of sense as an option in UMA, just as it will in OAuth. The real question here is whether or not the OAuth WG will ever get around to defining what a PoP token actually *is*. We’re kinda slow in that regard. :) But the important thing here is that UMA should be able to inherit PoP style tokens without doing extra work (or extra profiles). Basically, the “RPT as a Bearer” profile goes away entirely because it’s just another access token, and “RPT as a Bearer” is effectively defined by RFC6750 in entirety. [ Caveat: yes there are some small details that would need to be included in UMA still, but it’s tiny. ]


Bob never sees or uses the authorization endpoint. Bob never needs an account (federated or othewise) at the AS that is capable of doing regular-user stuff like issuing OAuth tokens. The AS doesn't have to carve out special "external" accounts that only allow for the "uma_authorization" scope but not act as regular OAuth resource owners. (Remember, this is Alice's AS, not Bob's, and Bob has no business getting a regular OAuth token here.)

The AAT isn't needed for anything since Bob's client is identified directly and Bob is identified through claims (which already exist). The client could further be identified through claims if it wants to.

The RPT endpoint isn't needed since this is now just a slightly-specialized OAuth grant type. Many systems (including our own) already have hooks for extending with handlers for new grant types as this is once place where OAuth is *already* extensible. In our own implementation, we'd get handed the request from the token endpoint handler (which already validates the client and syntax of the input among other things)

The JSON response from the protected API isn't needed either since the ticket is a single string and can easily (and safely) be passed back in a header. ( again this is another issue but if we're breaking all wire compatibility let's get it right... and a note on the returning-the-ticket-as-a-header thing. It also opens the door for public API responses and discovery of multiple user stuff, like this (totally off the cuff):

Public data can be solved like: Bob's client talks to a URL with no token and gets back some data, but a header that says "if you want more go to this AS and present this ticket.

Multi-user data (like the userinfo endpoint) can be solved like: Bob's client talks to a URL and gets sent back a header that says "if you want more then give me an indicator of who you're after (an opaque token, a webfinger URI) or go to this interactive page to have Bob figure it out, then come back and we'll talk again". Basically, you can bootstrap the process with some user interaction that could lead into George's multi-stage protected discovery system.  )


Someone is going to have to explain to me what is possible in the current system that is not possible in the above setup, because I'm not seeing anything.

Can we build it like it is today? Yes of course; I've done so myself. It works, but it's clunky and ugly and requires lots of special "if-uma-do-this" kind of code. I don't like that. It also requires Bob being able to do a regular OAuth flow to get the AAT even if he's not a local user, and I don't like that either.

So let's say we did things this way and called it UMA 2.0.0 (since this is a very backwards-incompatible change set and the group has adopted semantic versioning). What does that mean for me as a developer? Quite frankly, it means a whole lot less special code for implementing UMA at the AS, the client, and the RS, assuming I'm starting from an OAuth system. And it makes it much, much easier for me to have dual-purpose codebases that do both UMA and OAuth. Both of these are highly appealing to me as a systems architect and developer, and I don't think that I would be standing alone in this opinion.

You’re definitely not alone.

You’ll see from my previous message that my recommendation was for taking this up as a major version exercise. Now, having seen this more complete proposal, I’m more confident that we can actually get to the end of a design process like this without angst — I just think we shouldn’t attempt it for the patch workstream. :-)


I wholeheartedly agree that this is not a candidate for a patch release, and have said as much all along. :) I still believe that there shouldn’t be any breaking changes without backwards-compatibility shims in a patch release, and that “1.0.0 -> 1.0.1” should not be treated in any way as “special” in that regard. And I also believe that work on “UMA 2.0.0” can start right now along side “UMA 1.0.1”, (and even “UMA 1.1.0” if people really want it).

 — Justin

Eve



  -- Justin

On 8/6/2015 1:29 PM, Allan Foster wrote:
In the discussion there was talk of the new flow,  and how we get Bob's consent.

It came to me that we are only talking about using the token endpoint, at the moment.  In order to collect claims about Bob, wouldn't we need to use the User Endpoint?

If so,  this should happen early in the flow,  and is where the actual consent can be captured

Allan



On 8/7/15 1:05 AM, Eve Maler wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06

Minutes

Roll call

Quorum was reached.

Minutes approval

MOTION: Approve the amended minutes of UMA telecon 2015-07-30. APPROVED by unanimous consent.

APAC-friendly sync update

This sync schedule is working really well.

Spec versioning process update

No update. Eve hasn't moved the repo over.

Issue resolution work

Issues 153 and 154

Not meaning to guess Justin's exact thought process in any way...

Observation #1: AS has a special "RPT endpoint", making up the entirety of the special "UMA authorization API", at which the UMA client asks for a special UMA "RPT" with authorization data on Bob's behalf, that acts suspiciously just like an ordinary OAuth token endpoint. If it were more like an OAuth token endpoint, greater UMA-OAuth alignment could be achieved.

Observation #2: The UMA "authorization API token" (AAT) is an extra layer and hindrance to the entire OAuth-friendly cycle in this case, particularly because it appears to require that Bob have a login at the AS.

Discussion: Isn't the last bit, about the login, just an implementation decision? He has to either be SSO'd into the AS, or have a local login at the AS, or be offered a federated ("NASCAR-like" or whatever) login option at the AS. More accurately stated, he has to be able to establish an authenticated relationship with Alice's AS.

Observation #3: If the AAT flow were entirely removed and the RPT endpoint were turned into a ordinary token endpoint, then Bob's client would approach it to ask for "an access token" (perhaps of some UMA-flavored type?).

Discussion: Eve contends that, since we are trying to keep everything as much the same as possible, then this new "UMA-flavored grant flow" would still (so far) have the the client approach the RS, fail, get a ticket, go to the AS's (now) token endpoint, ask for a token, and engage in the trust elevation flow we have already designed.

Observation #4: Instead of using an AAT in the header of the token request, it would use its client credentials to identify itself, basically using its own recognizance.

Discussion: Where else is the AAT required in headers? Is it required in the redirect of Bob for claims-gathering? No, there are other security measures imposed. What about in the case of an autonomous web service client? We think that this could use pushed claims to the token endpoint as well.

More discussion: The AAT isn't very high-value! So a kind of "merge" to elevate what was the AAT flow up into what was the RPT flow to become an analog of a typical OAuth flow looks attractive. That means the claims flow would be the very first thing Bob does – no AAT step before. That seems kind of clean as a UX, if we're not missing anything like Bob's consent. And we don't think we're missing that, because that's what the OAuth flow is designed to do. The RPT represents everything the AAT did, but more. Why didn't we consider this before? In fact, we did.

More discussion: In both the authorization API circumstances and the newly imagined grant flow circumstances, how does Bob know exactly what claims the client is pushing?

Observation #5: UMA is still OAuth++ or value-add or something, in that the protection API that makes the AS and RS loosely coupled and makes possible trust establishment between them (using OAuth) is added on top, and in that Bob is a completely autonomous actor wrt Alice (which is why the grant flow we're considering has trust elevation as a key part of it), and in that the grant flow we're considering has asynchronicity as a key part of it. All the value-add still seems to adhere even if the AAT isn't part of the picture.

Discussion: Regarding the Privacy concerns: if the Client does a POST on the RPT to get the AuthzData added to it, the AS can still decide to return a new RPT to the Client (if the presented RPT had AuthzData for another RS attached to it). So that could be a AS-privacy setting? According to the APAC discussion yesterday, the answer appears to be yes. We can use a MUST to force the AS to mint a new token per RS. (Justin also noted in email that if the client tries to present a token from RS1 for upgrading with authorization data for RS2, the AS should not allow that.)

Discussion: Is UMA all pseudonymity-based? The AS knows Alice by AliceID(AS). The AS knows Bob through some set of claims, potentially. Each RS knows Alice by AliceID(RSn). Each PAT is a kind of pseudonymous federated ID by which both the AS and that RS know Alice. Each client has a set of access tokens (in the putative new solution) with a set of permissions, but not identifiers.

Discussion: How would the client manage multiple access tokens? All it knows is that it's trying to access a resource. How would it know that the token it has been given is new for this RS? What if the spec said this (bold is new)?

"If the client did not present a token in the request for authorization data, the authorization server creates and returns a new token. If the client did present a token in the request, the authorization server returns the token with which it associated the requested authorization data, which MAY be either the token that was in the request or a new one. In any case, the authorization server MUST return a new token when the client presents a token that is associated with a different resource server."

Summarizing our sense: Generally positive about most aspects, but there is a concern about how clients handle the token situation, and some uncertainty about ensuring that the requesting party really has a chance to authorize the interaction.

Next steps:

  • AI: Eve: Develop swimlanes (web sequence diagrams) of the putative new flows, along with pros and cons, and share with the group by Monday.
  • Let's TRY and have an active discussion, drawing in Nat, about the client concerns, before next Thursday.
  • Let's TRY and conclude issues 153 and 154 in the early part of next Thursday's meeting. If we have a specific proposal in front of us for issue 165, we'll consider it, otherwise not. We'll also take up 160, 161, 162, and 168 next time.

Regrets for next time: Andi, Robert, François, Ishan, James, Domenico. Ooh, next week is going to be tough for quorum, so everyone else please try and attend if they can!

AI status

  • AI: Thomas: Review the charter for potential revisions in this annual cycle.
  • AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted.
  • AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG.
  • AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework.
  • AI: Mike: Write SCIM protection case study to highlight client claims-based use case.
  • AI: Maciej: Write as many sections for the UIG as he can.
  • AI: Justin: Write a UIG section on default-deny and race conditions.

Attendees

As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike)

  1. Eve
  2. Andi
  3. Irwin
  4. Domenico
  5. Maciej
  6. Robert
  7. Mike
  8. Arlene
  9. François

Non-voting participants:

  • Adrian
  • James
  • Rene
  • Mark
  • Ishan
  • Allan
  • Jin

Regrets:

  • Thomas
 

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com



_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma




_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma


Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com