UMA telecon 2014-02-20

Owned by Eve Maler
Last updated: Feb 20, 2014

UMA telecon 2014-02-20

Date and Time

Agenda

  • RSAC UMAnitarians-and-friends drinks next Wed
  • HIMSS coordination (we have not prepared a custom demo video)
  • Webinar and upcoming meeting planning (and "summertime skew" reminder)
    • Including IETF (Mar 2-7 in London), IIW (May 5-8 in Mtn View)
  • Update on interop plans
  • Core 09f and claim profile review
    • Do a WG ballot (and an all-member ballot after)?
  • Other interop planning news
  • AOB

Minutes

RSAC

Shall we dub our drinks hour "UMArgaritas"?

HIMSS

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.

Webinar planning

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.

Upcoming meetings

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. (smile)

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.

Claim profiling

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:

  • Redirect type: client redirects RqP to AS ("pull"?): this pattern enables different role choices:
    • AS is a federated RP (OIDC, SAML, etc.) = AS acts as xxx RP (amenable to "sample" standardization)
    • AS holds RqP's local account (AD, LDAP, NoSQL, etc.) = AS pulls RqP's identity during authn (needs to be profiled by third parties)
  • Delivery type: client pushes claims to AS ("push"): this pattern also enables different choices, but we can be agnostic (we think – could be further profiled by others) as to whether the client was in the role of an actual IdP or was in the role of an RP in order to come into possession of those claims:
    • Client pushes OIDC user claims (obtained from some user_info endpoint) to AS = Client Acts as OIDC ID Token Conveyor (misnamed)
    • Client pushes SAML assertion to AS = Client Acts as SAML Assertion Conveyor (amenable to "sample" standardization, and could usefully be further profiled to specify the attributes in question, trust elements, etc.)
    • Client pushes OIDC ID token to AS
    • Client pushes X.509 cert to AS
    • Etc.

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.

Attendees

  • Eve
  • Thomas
  • SteveO
  • Adrian
  • Dan
  • Sal
  • Maciej
  • Lukasz
  • Jin
  • Domenico

Regrets:

  • Roland
  • George
  • Jin

Next Meetings

  • All-hands meeting Thu Feb 27 8:30-10am PT (time chart) - Mark, Adrian regrets
  • Focus meeting Thu Mar 6 8:30-10am PT (time chart)
  • No meeting Thu Mar 13 8:30-10am PT (time chart) - Eve regrets
  • Focus meeting Thu Mar 20 8:30-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew"
  • Webinar Thu Mar 20 8-9am PT (time chart) followed by focus meeting 9-10am PT (time chart) - N.B.: US has changed clocks by now - "summertime skew"

Â