Quorum was reached.
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:
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.
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.
Let's cancel May 8 and 22. Main goals: Interop, claim profiling, prepare for June webinar.
Reports: none.
How can we make headway? We don't have a common agreement on what APIs to use. Is it enough:
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:
No news.
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.
As of 24 April 2014 (pre-meeting), quorum is 6 of 11.
Non-voting:
Regrets: