UMA telecon 2013-01-03

Owned by Former user (Deleted)
Last updated: Jan 03, 2013

UMA telecon 2013-01-03

Date and Time

  • Focus meeting on Thursday, 3 Jan 2013, at 9am PT (time chart) – technical, educational
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • Report from latest spec editing sessions and prioritization of open issues
    • AS configuration data refactoring: discuss latest proposal
    • Token introspection profiling: discuss Justin's input
    • Review list of breaking changes
  • Security considerations/threat model review and planning
  • Plan terminology changeover in other UMA publications
    • Binding Obligations
    • Circle graphic
    • Use cases and case studies
    • Other
  • AOB

Minutes

Report from latest spec editing sessions and prioritization of open issues

Links: core spec, resource set registration spec, token introspection spec, config data proposal, breaking changes 

  • AS configuration data refactoring: discuss latest proposal
  • Token introspection profiling: discuss Justin's input
  • Review list of breaking changes

Justin joined us to explain his token introspection spec. It separates out a unique token introspection endpoint, vs. the Paul Madsen/Bryan Campbell draft that conflates endpoints and creates a new grant type. He's already using the spec for a couple of use cases. His design reflects experience from AOL's token introspection pattern and the UMA pattern as well. He's trying to factor out common metadata. George asks what about token content data, not just metadata? The intent is to just extend the JSON structure in the response in the normal way. One of MITRE's research groups is working on a sophisticated authorization engine, which is going to have an introspection endpoint. It will be handed the user's ID token, and will return the current user state. It will use a system-wide access token as the credential for the protected endpoint.

The metadata will probably be renamed along the lines of the new JOSE and JWT work, e.g. "user_id" goes to "sub" for subject. The client_id would be interesting if what it means is the client that originally presented this token. The audience would be interesting if it's used for constraining who the token can be passed on to, in chaining use cases. The driving use case is for the RS to use this endpoint, not the client, though maybe the latter would be interesting too.

The attempt to incorporate a normative reference to, and profiling of, the token introspection spec from UMA tries to pick and choose which metadata to use. Is it reasonable for UMA to just be silent on any metadata it doesn't see a need for now, to enable further profiling and even "tunneling" vanilla OAuth on top of UMA flows. The scope metadata in particular could be interesting for the latter. In an OAuth-enabled ecosystem that is only partially UMA-enabled, you could count on using the scope member in the normal way.

George suggests that Justin's spec make clear that any metadata members that appear MUST reflect the token's content.

Consensus: We'll remove our "constraints" on the standard metadata, and allow others to profile these details on top if they want.

Regarding our removal of the resource set ID and host ID in the request, it appears that host ID is superfluous because the PAT is sufficiently identifying of the RS. Consensus: Let's remove it. Given that UMA could have lots of different RPT profiles, some of which make UMA act more like XACML in its PDP/PEP functional separation, it would be handy to allow the RS to provide additional authorization context (such as the client's IP address) as a kind of "advice". However, does this overload the function of simple token introspection? Or is this fair game in terms of interpreting the "token contents" as being highly volatile, variable, and dynamic? It seems we're in agreement on this point. George suggests that Justin add a specific allowance for additional input parameters in his spec. Is a resource set ID common enough to be included (even if optionally) in Justin's spec directly? The OAuth Resource Set Registration spec defines an identifier format, and some other projects are already using URIs for this. George thinks it's warranted to add it to the generic spec, and for now we can remain silent on whetherh to use it or not.

Note that Justin has asked for the OAuth group to take up this spec, but they haven't done so yet. He's implementing to the spec already; our risk in using it is mostly around having added breaking changes to the UMA spec. The anticipation is that with OAuth core, token revocation, etc. wrapped up, it might be taken up. He's updating the spec on GitHub.

Spec note: We need to document the configuration data changes for token introspection.

Discussion of the config data proposal:

Why have a flag in addition to the endpoint for dynamic client registration? Mere presence of the endpoint means that it's supported. OpenID Connect is doing this for its discovery endpoint. They use Webfinger (not fully incorporated yet) and .well-known. Consensus: We agree that we don't need an additional dyn client reg flag.

Regarding the pat_*_supported ideas: The supply of a simple string like "bearer" looks ambiguous, given that OAuth bearer and UMA bearer are different! Can we make it clear that there are well-known short values that are basically reserved keywords, and RECOMMEND or REQUIRE that any additional values need to be URIs? Consensus: Let's do that. We can look at the JOSE specs for their example of defining field types. Also look at our own claim_profiles_supported property; it almost has the right wording. (Instead of "assigning", "providing" would be better.)

AI: Eve: Revise core spec to the 07b level according to the 2013-01-03 consensus.

Security considerations/threat model review and planning

Links: latest OAuth threat model spec, Domenico's and Eve's comments 

Deferred till next week.

Plan terminology changeover in other UMA publications

Links: circle graphic (attached to old UMA Explained page), Binding Obligations, case studies 

  • Binding Obligations
  • Circle graphic
  • Use cases and case studies
  • Other

Deferred till next week. Domenico has already edited the circle graphic for consideration.

Attendees

  • Eve
  • Alam
  • Keith
  • Domenico
  • Thomas
  • Maciej
  • Lukasz
  • Justin (subject-matter expert on the token introspection spec)
  • George

Next Meetings

  • Focus meeting on Thursday, 10 Jan 2013, at 9am PT (time chart) - technical, educational - Gluu OX demo