UMA telecon 2012-02-09

Date and Time

• WG telecon on Thursday, 9 Feb 2012, at 9am PT (time chart)
  • Skype: +99051000000481
  • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

• Roll call
• Approve minutes of 2012-02-02 meeting
• Tweet chat review
• Interop planning
  • Review Cordny's test cases and OpenID Connect interop progress
• Work through issues
  • Extension mechanism for JSON properties? (email)
  • Explicitly mention "bearer" rather than "artifact" for MTI token type? (email)
  • Remove IP address hint from host to AM? (email)
  • Is client_credentials the right grant-type choice for multiple requester tokens? (email)
  • JSONified config data okay? (edits from last week)
  • Conformance flag around policy handling? (Gerry B discussion)
  • 31 (baskets)
  • 41 (JSON media types)
  • 7 (caching language)
  • ...
• Review any other open AIs not already discussed
• AOB

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2012-02-02 meeting

Minutes of 2012-02-02 meeting APPROVED.

Tweet chat review and open-source plans

See the published chat online.

We should set up some best practices for how to respond to questions in the flow of the chat. We can remind people about tools like Muuter at the beginning.

Maciej broke some news in the thread! SMART is preparing a blog post on how to use the Python implementation ("PUMA"). And there are plans to open-source PUMA and UMA/j by the end of March. There was interest expressed in UMA implementations in Ruby on Rails as well, and in the current open-source plans.

Should we make this chat a regular thing, perhaps with a broadened scope and coordination with John and Nat? Maybe a monthly one makes sense. George, Maciej, Eve, and Thomas at least are willing to do this on a monthly basis. March 14 at 9am PT will be the next one.

Arnie would like to demonstrate a working prototype model after the CommIT meeting May 2-4 in Las Vegas. He needs to leverage existing code. This timeframe could work pretty well. We can help Arnie put together presentation material and use cases.

Interop planning

Cordny sent logical test cases for review.

PUMA will be available as a test AM and host whose endpoints various other entities can use for testing. What we should do for virtual interop activities is that all participants should publish their UMA configuration info. In addition, we should publish the test cases as explanatory resources for now (and normative eventually). Should we standardize on some kind of protected-resource API we can all agree to target? Participating host endpoints would have to publish not only their scope descriptions, but also their full API documentation.

The PUMA implementation's host is a personal data store, which serves up identity claims. The API just allows GETting data. What does the Fraunhofer host implementation offer?

Work through issues

• Extension mechanism for JSON properties? (email thread)

Paul finds is unable defend the "x-" notation in retrospect. There's a usability problem with URIs. Reverse domain names a la Java are another option people seem to like. And St. Peter made an explicit proposal on this: draft-saintandre-json-namespaces-00. Can we just say that extension names that are unprotected from collisions are not our problem? Yes.

• Explicitly mention "bearer" rather than "artifact" for MTI token type? (email thread)

We have consensus to do this. This should be a relatively small change to the spec, though backwards-incompatible in that the token type value changes to "bearer" in the AM configuration info. We'll also have to normatively reference the bearer token profile spec.

• Remove IP address hint from host to AM? (email thread)

We already allow the AM to assess whatever factors it wants in assessing the viability of the requester's request for permission. Do we need to invent the equivalent of an "Advice" bucket a la SAML for the host's communications with the AM? Or does the ability to extend the JSON structure at various points suffice for this kind of extensibility.

When it comes to proxying, there are standard things that get looked at for security analysis: XSF header, IP address, etc. Who is responsible for determining whether the resource should be provided to the requester? The AM's responsibility includes claims-checking and possibly other requester-independent factors, such as time of day. The AM is not in a position to test any host-dependent factors that the host has not otherwise informed it about (that is, fine-grained access issues outside of whatever was exposed in the scope desciptions that were registered). The AM also isn't in a position to trust the host if it conveys its observed context about the requester, since the host and requester might be colluding. The only thing the AM can trust the host for is host-dependent factors, and this could be handled in extensions as necessary.

So we're agreed to remove the IP address piece.

AI: Thomas: Remove the host's option to pass along the IP address to the AM.

• Is client_credentials the right grant-type choice for multiple requester tokens? (email thread)

We might indeed need to look at an extension flow instead of using plain client_credentials. The requester could give the AM a unique ID or index representing the authorizing user, so that the AM knows which token to give back. Could we be inspired by OpenID Connect choices here? If the AM were to take the ID and encrypt it and put it in the refresh token, then every time the requester shows up again with the refresh token, the AM knows exactly what to do.

We need to discuss this more and solve the issue.

Next Meetings

• WG telecon on Thursday, 16 Feb 2012, at 9am PT (time chart)
• WG telecon on Thursday, 23 Feb 2012, at 9am PT (time chart)

Attendees

As of 1 Feb 2012, quorum is 7 of 13.

1. Mohammad, Alam
2. D'Agostino, Salvatore
3. Fletcher, George
4. Hardjono, Thomas
5. Machulak, Maciej
6. Maler, Eve
7. Miles, Arnie
8. Szpot, Jacek

Non-voting participants:

• Bryan, Paul
• Cox, Kevin

Regrets:

• Moren, Lukasz