UMA telecon 2013-03-07

Owned by Former user (Deleted)
Last updated: Mar 07, 2013
6 min read

UMA telecon 2013-03-07

Date and Time

  • Focus meeting on Thursday, Mar 7, at 9am PT (time chart)
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • Action item review
  • Comment on/validate Nat's candidate flows for Alice-to-Bob sharing
    • Claims of varying types
    • Initiation direction
    • Policies for requester app as well as requesting party? (Thomas comment/SMART implementation)
  • Review/discuss Keith's work on NSTIC-flavored case studies and UMA-protected OpenID Connect, as available
  • Wake up feature test review
  • AOB

Minutes

Action item review

We refreshed this AI:

2012-11-15-5Keith, SMART teamReview the Gluu/OX UMA tests.InteropKeith has reached out to Mike Schwartz. He will clarify with Yuri what we're looking for.

Keith also offers to review/test the UMA standard slide decks.

Comment on/validate Nat's candidate flows for Alice-to-Bob sharing

  • Claims of varying types
  • Initiation direction
  • Policies for requester app as well as requesting party? (Thomas comment/SMART implementation)

The requirements:

  1. Alice needs to give permission to Bob to access her resource;
  2. The resource needs to be able to find out the fact that Alice has given the permission. (policy);
  3. The resource needs to make sure the entity that accessing it is Bob;

Eve comments that the last two instances of "the resource" here, in #2 and #3, really mean the resource server. Alice is giving access to "a resource" that might be one calendar among many other resources on a server; it's that server that needs to "find out" and "make sure" of things.

Assumption:

  1. Alice and Bob has OpenID Connect Identity provider (OP) of their own;
  2. The resource has been registered at Alice’s authorization server and the accounts at the resource and the authorization server is linked somehow.;
  3. Alice has to know Bob’s identifier in Alice initiated flow, and Bob has to know Alice’s identifier in Bob initiated flow.

We agree with #1. We agree with #2; the link is forged through UMA's "step 1", when Alice introduces one to the other. On #3, it may be premature to set assumptions that are flow-specific, because the flows may introduce design choices that UMA and OpenID Connect may or may not make. Further, it's a question what "initiation" really means. E.g., if Alice advertises her calendar on her blog, and Bob "initiates" an attempt to access the calendar, he didn't need Alice's identifier explicitly; an implicit context gave him the knowledge. And if Alice wants to allow Bob to access a resource based on characteristics other than a unique identifier, she can use UMA to do it (through the broader ability to ask for claims). In fact, the demo we did in the Google Tech Talk showed SMARTAM using policies over non-identifier claims to ensure that it's only Bob getting access (verified bob@gmail.com)! It would be more certain to be Bob, perhaps, given the low strength of password security, if Alice asked Bob to prove that he 1) is a US resident, 2) lives in a certain ZIP code, 3) is of a certain gender, and 4) has a certain birth date. The UMA AS is an OpenID Connect RP/client and is going to be exposed to Bob's OIC identifier therefore, but that's not the same thing as saying that Alice has to make a policy that depends on knowing it. Net: We think #3 has to be reconsidered somehow.

There can be two kind of work flow:

  1. Alice initiated flow (Alice giving the permission to Bob and Bob access the resource);
  2. Bob initiated flow (Bob requests the claim; Alice approves it; Bob access the resource);

We agree with #1. There is some subtlety around the meaning of #2. The SMARTAM implementation actually did demonstrate a feature in the Google Tech Talk whereby it can queue unsolicited requests for access, for Alice to approve whenever she next visits the AS. This isn't a policy so much as it is an application-level (value-add) feature. In fact, Google Apps works this way with the added simplifying assumption that the people requesting access are, by definition, in a single known namespace (the company's domain). If the desire is to have a Liberty Interaction Service kind of flow, which has to support callbacks to enable polling, that's a bigger challenge than asynchronous flows.

AI: Lukasz to demo the CloudIdentity solution, particularly around requesting-party-initiated flows, in next week's call (to be recorded).

WF1: Alice initiated flow (Alice giving the permission to Bob and Bob access the resource)

This is an Alice initiated flow. In this workflow, it proceeds as follows:

  1. Alice access the endpoint that let her create the policy / authorization (AM in UMA?) for Bob to access her resource;
  2. Alice is redirected to her OP and gets authenticated and bounced back to the AM;
  3. The AM shows Alice the URL that Bob can use to access the resource. (Note: URL may have the policy encoded in it so that the servers can be stateless) In Link-Rel terminology, the type of the resource (e.g., the medical test result) is ‘rel’ and the URL is the ‘link’;
  4. Alice sends the URL somehow to Bob (e.g., email);
  5. Bob access the URL;
  6. Since URL is protected, Bob is bounced to his OP. (Note: At this point, the resource server has to be registered at Bob’s OP as a client.) ;
  7. OP authenticates Bob and bounces him back to the registered redirect URI, say with ‘code’;
  8. The resource accesses the token endpoint of Bob’s OP to get his ID Token;
  9. The resource examines the ID Token and finds out that the person accessing is Bob through the ‘iss’ and ’sub’ claim;
  10. The resource returns Alice’s medical test result to Bob’s browser;
  11. The trick here is the ‘link’. The ‘link’ has to contain some state information that can be used to look up the policy that Alice has set. It could either be completely encoded in the URI or the resource server may resolve the policy from the state. Apart from that, there is nothing special. It is just the standard OpenID Connect repeated twice; one each for Alice and Bob. Also, it would be worth noting that to achieve this, Alice somehow has to know Bob’s identifier, such as email so that Bob can prove that he is the legitimate holder of that identifier.

#1 should be "AS" now, since UMA uses OAuth terminology. Otherwise it looks good.

#2 seems to assume that Alice's AS leverages her OP for authentication, which is fine. In our call with Nat, we made the simplifying assumption that her AS was her OP, but it's not required. If an OP appears in WF1 because there's a presumption that Bob is going to need to know things about Alice, we don't think that's the case. So we need an explanation of why, exactly, this is here; it looks like it's not leveraged until WF2. For now, let's assume that indeed her AS is not colocated with her OP and leverages it for authentication. This is much the same scenario as the SMARTAM demo in the Google Tech Talk, which showed the AM (as it was called then) leveraging Facebook – and other providers -- for authentication and other user data.

#3 is not required by UMA, but SMARTAM has indeed implemented a feature whereby when the RS registers a resource with the AS, the AS constructs a URL that Alice can share with others whom she wishes to get/seek access. It would be easy for the AS to generate an email that lets Alice "advertise" the resource in this way. UMA puts no requirements on that URL; it could be absolutely plain and generic, with nothing Bob-specific in it, and the back-end policy and claims-gathering etc. will still work. However, we have contemplated useful ways to put more data in the URL, e.g. using the web-keys system of cryptographically binding the URL to the person to whom it's being sent. (Eve thinks it's crazy to actually distribute capabilities this way, but it's useful for auditing whether Bob "let the cat out of the bag" in sharing that URL further.)

#4 and #5 look fine according to UMA; #4 is application-level functionality.

#6 doesn't align perfectly with UMA as specified today. The RS, on learning that the access token "doesn't have sufficient authorization data" (as the spec puts it), sends Bob and his client to the AS. It's the AS that is an OIC RP/client and that ultimately bounces Bob to his OP. Thomas's comment on Nat's post suggests that Alice can make policies about Bob's client as well as Bob. Eve believes this isn't possible in UMA as currently specified, although the SMARTAM implementation is suggestive of how it might work in some fashion. We'll work on this next week and the following week.

Attendees

  • Eve
  • Keith
  • Alam
  • Domenico
  • Lukasz
  • Maciej

Regrets:

  • Thomas

Next Meetings

  • Focus meeting on Thursday, Mar 14, at 9am PT (time chart) – Lukasz will demo
  • Focus meeting on Thursday, Mar 21, at 9am PT (time chart)
  • All-hands meeting on Thursday, Mar 28, at 9am PT (time chart)