Shall we dub our drinks hour "UMArgaritas"?
Thomas notes that he and Adrian are holding a workshop at MIT on handling health data, to foster more dialogue around putting patients in the loop.
What should we do about HIMSS? Eve hasn't made any progress on her plan to do a new version of the demo video that's healthcare-flavored. Adrian feels it's still valuable to suggest to Pete Palmer to show the demo video we do have, and/or share a quick blurb about UMA and point people to the slide deck about the IDESG RLS use case mapping.
AI: Eve: Send mail to Pete and coordinate with Adrian on a HIMSS presence for UMA.
We confirmed the timing. Gluu's case study will be the main attraction, with some light participation from Cloud Identity, CA, and ForgeRock. Eve's got the planning under way.
We won't meet Mar 13 because Eve can't make it. Please note the "summertime skew" effects of the schedule. We meet on US time, not GMT-relative.
Steve is going to IETF and IIW. Adrian is going to IIW.
Does it make sense to plan a F2F interop session at IIW? Let's pursue this; Maciej can bring it up at the interop meeting he's planning.
Maciej explained the rationale for the claim profiling framework he's written up. Eve asks if "pull" and "push" are good concepts to explain the paradigm of the framework. They might be helpful. Here's a way to understand the framework:
Eve comments that the "claim_value" property in step 2 of the redirect framework should be called something like "redirect_URI". The redirect framework enables the client to be as "dumb" as possible; it doesn't need to know anything about what type of RP (or whatever) the AS is, it just has to handle the double redirect gracefully with good UX for the RqP. The redirect framework cleverly uses the need_claims response to communicate what's required next for the client to do. Providing the redirect URI dynamically could be handy but also possibly insecure; this could be a matter for the configuration data.
Should the push model reuse the existing authorization request endpoint? We think so, but the AS has to advertise that this model is possible so that the client knows it can push claims and what form they should be in. This is where the config data would need to have claim_profiles_supported in good order.
Are we okay with Maciej's proposal to require JSON for the claims, so that (e.g.) SAML has to be base64-encoded? Yes. The rationale is to unify the body format that clients have to produce, and that authz servers have to parse.
Are we okay with keeping the claim profiling stuff entirely outside the core spec? Yes.
What about the language of the two frameworks? Eve likes "Client Pushes Claims to Authorization Server" and "Client Redirects Requesting Party to Authorization Server". And what are these types of profiles, given that they're meant to be further profiled? Extensibility? Framework? (nothing)? Let's leave it to Maciej's choice.
AI: Maciej, Domenico: Put claim profiling spec into xml2rfc shape.
Regrets: