UMA telecon 2014-01-16

Owned by Eve Maler
Last updated: Jan 16, 2014
5 min read

UMA telecon 2014-01-16

Date and Time

Agenda

  • New Core draft 09a (now uploaded) for consideration, with AS=C changes
    • Spec and interop questions around our "requirements" for HTTP over TLS
    • SAML grant flow question
    • Other issues coming up as a result of feature test discussion
    • Any other issues on GitHub worth discussing
  • Other interop planning and uma-dev news
  • Discuss next stage of terms of authz/binding obs work
  • Webinar update
  • AOB

Minutes

New Core draft 09a

We reviewed the new AS=C wording.

We need to make some further tweaks, e.g., from: "When the system entity-as-client detects that it needs to ask itself-as-authorization server to add authorization data to an RPT, a response MAY be issued directly without requiring explicit use of the authorization request endpoint or presentation of an AAT, RPT, or ticket in any request, and the client MAY use non-HTTP means of redirecting the requesting party over to the authorization server." to something like: "When the system entity-as-client detects that it needs to ask itself-as-authorization server to add authorization data to an RPT, a response MAY be issued directly without requiring explicit use of the authorization request endpoint or presentation of an AAT, RPT, or ticket in any request, and the client MAY use non-HTTP means of enabling the supply of claims to itself-as-authorization server."

Also, there's a typo in the first line! s/authorhization/authorization/.

Also, we should change from the phraseology "needs to request" to simply "needs", so that we don't imply that it's pulling anything.

Now, for the philosophical question: is full non-optimized use of UMA mandatory to implement, or not? If you implement a library to get UMA functionality, it's easy to conform. If you have a highly specialized internal use of UMA, then maybe not, in that it imposes additional burden – but then, do you care about strict UMA conformance, interop-fests, and the like? Effectively, the AS=C profile replaces the authorization profile with something else. This also means that our phrasing, that is, "AS equals C", potentially overstates the case: The C might not literally be the same system entity, nor even operated by the same organization, but the two roles simply have negotiated an alternate agreement for communication.

We think it should be okay to make all of the HTTPS endpoint specifications be MTI, with the understanding that some implementors may choose not to go for "full conformance" to the entire suite of feature tests, but "partial conformance" along the lines of the alternate communication channels for the APIs. A consequence of this is that it slightly encourages anyone interested in the alternate communication channels to actually write a profile for them whenever they think they won't be using them entirely "internally" to their organizations.

We currently don't actually have as many MUSTs as we strictly need in order to effect this "mandatoriness", so we need to do some editing of Sections 2 and 3 to ensure that we have the right number of them. Maciej has been advocating for an approach to documenting optimization profiles' impact that would migrate the single health warning from Section 1.3 to all the places where the relevant MUSTs appear in Sections 2 and 3. So we discussed this again, and concluded that we should do this.

This decision also means that it would be valuable to organize the feature test buckets along API/communication channel lines.

How does using an alternate communication channel impact privacy? Would this be a matter for the Binding Obligations doc? We think it could be handled there, even if it's not yet handled explicitly.

What about the SHOULD mention of the SAML bearer token grant type? We think it's too strong. Keep the cross-reference but merely using it as a parenthetical example would suffice, so from: "The authorization server MAY support the use of any OAuth grant type for PAT and AAT issuance, but MUST support the authorization_code grant type, and SHOULD support the SAML bearer token grant type [OAuth-SAML] (urn:ietf:params:oauth:grant-type:saml2-bearer) if it anticipates working with entities that are operating in environments where the use of SAML is prevalent." to: "The authorization server MAY support the use of any OAuth grant type for PAT and AAT issuance (for example, the SAML bearer token grant type [OAuth-SAML]), but MUST support the authorization_code grant type [removed text]." This would also mean we can eliminate some optional feature tests.

AI: Thomas and Eve: Work on Core spec 09b to implement changes from telecon 2014-01-16.

Maciej suggests that we consider letting the RS register multiple permissions with the AS at a time. Roland expresses interest as well. This could be done through creating a single ticket; we don't see the value of generating one ticket per requested permission.

AI: Maciej: Sketch candidate spec text for registering multiple requested permissions.

Maciej suggests that it would be handy for the AS simply to refresh an old existing RPT, rather than invalidating an old one and handing out a new one. The spec text is potentially too implementation-specific in dictating token validity period handling. Did we mean to suggest that an old RPT and all of its authorization data needs to be revoked when the client makes this request? This is somewhat related to Maciej's additional suggestion that perhaps the RPT could either contain in-band, or enable the client to request through introspection, its own validity period. This would be at most a hint that the RPT is still valid, because it could be invalidated at any time. Currently the client only finds out that an RPT is no good when it tries to use it and the RS responds appropriately to an invalid RPT.

AI: Eve: Add an issue about exposure of RPT validity to clients to GitHub.

"Freedom Box" UMA deployment

Adrian is experimenting with an "HIE-of-one", so that an individual could host the relevant services themselves on a Freedom Box, e.g. supporting the BB+ protocols, Direct messaging, OpenID Connect, OAuth, etc. Could UMA be used in such a circumstance, e.g. with an individual running their own AS? Eve suspects this is certainly technically possible – that is, nothing prevents this technically. But she's not sure how this would play in an access federation/trust framework context, similar to someone running their own "self-issued" OpenID provider. Adrian's central question is how to combine privacy-preserving managed services with services that use keys entirely in a person's own possession.

BB+ has the concept of registries, and this conveys trust relationship information. Would the IDESG be able to solve the challenge of trusting an individual person's certificate?

IDESG report

Adrian reports that they announced Digital by Default, starting later this summer. It's a credential exchange with five competing identity providers, and a SAML-based hub. People will be able to choose which of the IdPs they want to use. Rollout will start slowly; an initial use case will be to show people's driver's license "points" (insurance infractions). People who aren't online will be handled separately. FCCX is an exchange for US federal agencies.

Funding for IDESG is changing up, so this will bring up some questions and potentially slow its progress. But it's clear the US federal government is still keenly interested in it, and the healthcare use case stands out as a motivating factor and a way to make progress.

The UK is planning to run through the Open Identity Exchange.

Attendees

  • Eve
  • Roland
  • Mark
  • Adrian
  • Jin
  • Keith
  • Maciej
  • Thomas
  • Domenico
  • Vicky

Next Meetings

  • Focus meeting Thu Jan 16 8:30-10am PT (time chart)
  • Focus meeting Thu Jan 23 8:30-10am PT (time chart)
  • All-hands meeting Thu Jan 30 8:30-10am PT (time chart)