[WG-UMA] Draft minutes of UMA telecon 2011-03-03

Eve Maler eve at xmlgrrl.com
Thu Mar 3 13:51:18 EST 2011


http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2011-03-03
Attendees
As of 24 Feb 2011 (post-mtg), quorum is 7 of 13.

Mohammad, Alam
Catalano, Domenico
D'Agostino, Salvatore
Hardjono, Thomas
Machulak, Maciej
Maler, Eve
Moren, Lukasz
Morrow, Susan
Wolniak, Maciej
Non-voting:

John Bradley
Kevin Cox
Mark Lizar
Cordny Nederkoorn
Frank Wray
Observer:

Bob Cope
Regrets:

Paul Bryan
Christian Scholz
Minutes
New AI summary
2011-03-02-1	Nat	Open	Put together JWT-compliant examples of Claims 2.0 and Simple Access Authorization Claims.
Roll call
Quorum was reached.

Approve minutes of 2011-02-17 meeting
Minutes of 2011-02-17 meeting APPROVED.

Action item review
2011-01-27-1	 Paul	 Open	 Revise the Claims 2.0 spec to reference and profile JWT.
2011-02-10-1	 Alam	 Open	 Share details of his planned UMA demo with the list. Very soon. Alam and Cordny are both presenting on UMA at the EEMA conference. They've been coordinating.
2011-02-24-2	 Susan, Eve	Closed	 Revise trust model according to the discussion from 2011-02-24.
Review of trust model work and TODOs
Jeff Stollman made some great comments on the list. One issue he brought up: Is "trusting" and "relying on" the same thing? In practical terms, should we switch to "trusting party" and, e.g., "User trusts host operator" (TR-1a)? Mark points out this could be described as a need for "confidence" in their actions, which has a social dimension. John warns about going in circles on terminology. Sal notes that we've got core relationship requirements that we need to record, and liability is a blunt instrument to be used only when things go wrong. Mark observes that indemnity is the other half of liability.

Let's keep the language we have, track Rainer's work over time in case the recommendations around "reliance" change, and scrutinize the verbs that currently appear in our "Expected behavior" column.

See Domenico's new diagramming trust graphic.
Thomas has long experience in defining technical trust (and other kinds of trust – social, business), including in hardware systems. He suggests labeling the arrows to say explicitly "A trusts B to...". Eve proposes that our TR-7a is really only talking about technical trust, and really the job of this document is to get as far as business trust. It seems like the layers go like this:

Technical trust (APIs/"contracts" between software or hardware components – this approaches "compliance" to specs or profiles)
Social trust (expectations about responsibilities)
Business trust (a model of liability/indemnity that applies to parties whose responsibility rises to the level of "duty")
The matrix is generally agreed to be valuable. The requester is kind of hanging out to the side; what should this mean? It's a good idea to remove the requester and keep the diagram just containing "parties", and then consider making a whole separate diagram for "endpoints" that can illustrate the technical-trust layer.

The danger in labeling 0 through 3 is that people will think of NIST-like Levels of Assurance! Maybe we should call them Llama, Alpaca, Chinchilla...

Next steps for progress on core spec revisions related to scoped access
Some details decided last week.
Right now, the implementer population is being held back by the lack of detail and accuracy in our core spec. We'll probably need Paul's help, but could also use other's help, to remedy this. Let's plan on doing a collaborative editing session for the week of Mar 14.

Review of previous day's Claims 2.0 discussion
See meeting notes.
The Claims 2.0 spec defines, and the Simple Access Authorization Claims spec utilizes, a "templating" trick where the claims-requested message that the AM sends to the requester looks like a wildcarded/regex version of the claims that are desired to come back in response.

The "( | )" trick seems really useful, particularly for issuers. The "*" trick seems useful but limited. John feels "<" and ">" operators would be very useful for privacy reasons, since it makes it easier to find out if a person is "over 18". And not having them available may lead to claims definition standards that are anomalous (a claim for "over 18", a claim for "over 13", etc.). But maybe we should be very cautious about adding new operators and adding data types. A lot of claims that we can imagine are relatively specialized or vertical; would requester software need to understand all of them, or would it have recourse to some kind of discovery service or catalog to find out where to go to get the needed claim? Discovery would be an added level of complexity. Then again, an OpenID Provider has to be a kind of discovery service, and so maybe we can point off to that.

OpenID ABC may be in the position of profiling or extending Claims 2.0! That sort of feedback would be important to listen to if we want Claims 2.0 to be a reusable modular for reasonable other purposes. JWT defines a "claims response message format", but is currently missing a request format. This is where our spec comes in.

We'll bring this up for discussion again when we have Nat's examples to look at.

Review rreg changes and issues
The SMART implementation enforces uniqueness of resource set identifiers among users at the host. We had made a decision not to require uniqueness of this sort, but maybe the book isn't closed on this. We need to spec the scoped-access stuff to fully see the consequences.

Next Meetings
WG telecon on Thursday, 10 Mar 2011, at 9-10:30am PT (time chart) – Eve regrets; Maciej to chair and publish agenda/minutes
WG telecon on Thursday, 17 Mar 2011, at 9-10:30am PT (time chart) – Eve may need to miss first part; Maciej to chair?
WG telecon on Thursday, 24 Mar 2011, at 9-10:30am PT (time chart)


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110303/9f25dc89/attachment-0001.html 


More information about the WG-UMA mailing list