UMA telecon 2014-04-24

Owned by Eve Maler
Last updated: Apr 24, 2014

UMA telecon 2014-04-24

Date and Time

Agenda

Minutes

Roll call

Quorum was reached.

Claim profiling work

See new draft from Maciej sent to the list. The main change is that there are four profiles defined, rather than emphasizing the two types of profiles (though there are still two types). The special endpoint to send human RqPs to is now renamed to "requesting party claims endpoint". We need more detail here on what parameters to pass, but this is a basic structure to work with.

Looking at Section 2.5.2: The "value" parameter shown in this section is meant to contain the relevant object specific to the claim type, so we should use a name that's more specific. Eve asks: Does the AS ever want to force the client to redirect the human RqP? Or should it leave the client to choose what it's able to do? What if it were to simply pass the state that the client is required to pass back, whatever claim profile it uses? This question goes back to step 3 in the Section 2 framework: What are the rationales, if any, behind having the AS declare what types of claim profiles it is willing to use in engaging with the client on claims-gathering? Maciej is thinking that the AS could potentially use this to dynamically ask the client to be sure to deliver specific claims. This is what we originally sketched out years ago, with the "Claims 2.0" etc., but in practice it appears that the set of claims of interest are defined out-of-band by trust communities in static fashion.

Basically, we have an opportunity for the AS to "push" data dynamically to the client within the need_claims block in its response to the request for adding authorization data. What do we want to use this dynamic opportunity for? The AS could push:

  • The redirect endpoint (now declared statically in the config data, per Section 2.5.1, not pushed)
  • The ticket
  • Other state
  • Which claim profiles are preferred/required to be used – Eve is a bit dubious about this since there's a static place to declare it as well – would it be valuable to use this opportunity to subset the available list of claim profiles supported?
  • Which claims are needed
  • What format the needed claims need to be in
  • The desired audience for the packaged claims – this may be obvious because it's just the AS itself (iow, no need to send)

Roland observes that, in SAML, the only way for an SP to tell an IdP what attributes it needs is through metadata (equivalent to our config data, i.e. statically defined). But we do have the problem, discussed previously, of how the client can convey/package the claims in such a way that the audience for the claims is a) appropriately restricted for security and b) inclusive of the AS, which is – in every sense – a relying party for these claims.

We still need to work on the naming of the profiles and also ensure there's a profile for "client pushes ID token". The OIDC working group has discussed what the audience value should be, given the "multi-audience world" we're in, but didn't come to any conclusions. JWT has a notion of a "presenter" that could split off. Discussions have happened about making "audience" etc. be lists. Maybe we need to treat this as a concrete use case of a specific set of audiences (the UMA AS as a claims client #2 coming in the chain after the UMA client as claims client #1 to some IdP). Can we open up a conversation with the OIDC folks about this use case, to come up with a good solution? The usability this would enable is huge – no excessive user redirecting etc.

Of course, if the UMA client is itself an IdP, it can craft whatever assertion/token format it wants, taking into account the knowledge it has of the UMA AS and therefore the necessary audience.

Approval of previous minutes

MOTION: Approve minutes of UMA telecon 2014-03-27 and read into today's minutes all intervening ad hoc meeting notes. APPROVED by unanimous consent.

Review May meeting schedule and goals

Let's cancel May 8 and 22. Main goals: Interop, claim profiling, prepare for June webinar.

AI review

Reports: none.

Interop and event planning

How can we make headway? We don't have a common agreement on what APIs to use. Is it enough:

  1. For each participant to provide an SDK for integration with their API?
  2. And/or to declare that all APIs need to at least be compatible with the "pbryan" API?
  3. And/or should we pick the SCIM (or FHIR) API or a similar one known to be implemented by some of the participants?

Note that the UMA client doesn't have to be a compliant API client, just to make correct-form API calls and accept compliant output gracefully. Eve is more worried about asking real-world RS's to change their plans and implement an API that they don't naturally have an incentive to implement. Roland's RS is meant for his real-world UMA+IdP use case, but he readily added a new front end that implemented the pbryan API.

So let's see if we can avoid making any momentous about this, by analyzing whether the Nuve PDS API is, in fact, compatible with pbryan. Assuming it is, perhaps our guideline should be:

  • Any API exposed by an RS participating in the interop MUST be pbryan-compatible.
  • If a participant claims hardship and is also prepared to expose a well-known, well-defined API such as SCIM or FHIR, and at least one other party participating in the interop also has an interest in that specific API, we can consider creating a results list subset for the testing among that sub-community.

Webinar planning if any news

  • Date: June 19, 8-9am PT
  • Theme: UMA, OpenID Connect, and personal data stores
  • Key participants: Maciej/Cloud Identity, Thomas/MIT-KIT, Dazza/MIT, and Nat so far
  • Hashtag: #UMApcloud
  • Sponsorships: ?

No news.

Case study work

Bob describes the use case: UMA uses claims-based access control, so you have to know "who you want to give access to". If it's a low-value resource being protected, a self-asserted claim might be okay. But if it's high-value, what to do? If the resource owner knows who they want to give access to – say, an access control list of specific individuals – and it's a high-value resource, is it really necessary to involve a third-party IdP? Why can't the resource owner directly provision a token to the party? E.g., this could involve a (FIDO-enabled?) key pair that the RO could directly provision to the RqP. Then the AS could verify the RqP's credentials.

Today's earlier conversation on claims profiling relates to this. The AS could demand a holder-of-key claim, for example, and this would strongly identify and authenticate the requesting party. The RO could also set policy that requires collection of a set of third-party-asserted but non-uniquely identifying claims (like "citizen of some country"). And the AS app could also help the RO by sending out emails with links (maybe one-time-use) and even one-time secrets out to intended RqPs. The RO could also require the RqP to be able to sign some artifact that the RO can verify using that RqP's public key. This latter idea was discussed extensively at a Privacy and Security working group meeting, and greeted with a positive reaction.

Do we really want to push actual authorization into the token shared ahead of time with the intended RqP? What we describe above is really about correlating claims of various types between the relevant policy and the RqP (claims-holder), vs. literally embedding authorization.

Note that Gluu's profile for trust elevation also has relevance here, since we need to be able to kick out the AAT if it wasn't forged with a strong enough RqP authentication.

Bottom line: UMA doesn't require high-value (or low-value) resources to be protected with any particular pattern of claims or with a predetermined list of desired requesting parties, and it enable a wide variety of variability in how policies (and required claims) are conceived to meet different dynamic and static permission use cases.

Attendees

As of 24 April 2014 (pre-meeting), quorum is 6 of 11.

  1. Eve
  2. Maciej
  3. Domenico
  4. Keith
  5. Jin
  6. Sal
  7. Thomas

Non-voting:

  • Roland
  • George
  • Adrian
  • Zhanna
  • Bob P

Regrets:

  • Mark (voting)

Next Meetings

  • Focus meeting Thu May 1 8:30-10am PT (time chart)
  • No meeting Thu May 8 due to IIW
  • Focus meeting Thu May 15 8:30-10am PT (time chart) - Roland can possibly attend
  • No meeting Thu May 22 due to absences
  • All-hands meeting Thu May 29 8:30-10am PT (time chart)