UMA telecon 2010-12-09

Owned by Former user (Deleted)
Last updated: Dec 09, 2010Version comment
6 min read

UMA telecon 2010-12-09

Date and Time

  • WG telecon on Thursday, 9 Dec 2010, at 9-10:30am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

  • Roll call
  • Approve minutes of 2010-11-18 meeting
  • Action item review
    • Add AI for OAuth draft 11 review and report?
    • Add AI for OAuth token review and report?
  • UMA validation bounty program status
  • Trusted claims
  • Resource reg spec
    • Catalog new issues based on review
    • Try to knock off low-hanging-fruit issues
  • Conformance testing questions
    • Review issues that are blocking conformance test plan completion
  • AOB

Attendees

As of 15 Nov 2010, quorum is 8 of 14.

  1. Alam, Mohammed
  2. Bryan, Paul
  3. Catalano, Domenico
  4. D'Agostino, Salvatore
  5. Fletcher, George
  6. Hardjono, Thomas
  7. Machulak, Maciej
  8. Maler, Eve
  9. Moren, Lukasz
  10. Morrow, Susan
  11. Scholz, Christian

Non-voting:

  • Kevin Cox
  • Cordny Nederkoorn

Minutes

New AI summary

2010-12-09-1

Susan, Thomas

Open

Review and critique the resource reg spec.

2010-12-09-2

Eve

Open

Revise the core and resource reg specs to reflect new decisions.

Roll call

Quorum was reached.

Approve minutes of 2010-12-02 meeting

Minutes of 2010-11-18 meeting APPROVED.

Action item review

  • 2010-11-01-2 Eve Open Put the public-private continuum language and diagram into the Lexicon.
  • 2010-11-18-3 Domenico, Sal Open Explore turning the trusted claims UX and writeup into draft spec text. Now closed.
  • 2010-11-18-4 Eve Open Capture new user stories in the wiki.

Add AI for OAuth draft 11 review and report? Maciej reports that his team has been examining draft 11 for the purpose of updating OAuth Leeloo. Before the software moves to the Apache Foundation they plan to upgrade it. The 10-to-11 document history is in the spec itself.

Add AI for OAuth token review and report? George attended all the IIW meetings where the new token work was discussed heavily. He will walk us through the new specs next time.

UMA validation bounty program status

Cordny's draft materials are available on the wiki. They need to be reviewed against the core spec.

Project hData has also shared initial draft materials. Sal and Susan have a particular interest in assessing their materials, and Sal has taken a look at the materials. Sal, Susan, Eve, and Maciej will form a sort of lightweight subcommittee for assessing the input from this team.

Trusted claims

Susan asks about the relationship of digital signatures to claims. There is a range of complexity possible, from full PKI to shared secrets and hashing. Can we get "lower" than that, with no claim-based signatures if the model is point-to-point? For example, Eve wonders if it's at all valuable for a requester (AM1) to ask Equifax (IdP/claims host) to tell it the digital subject is 18, if the digital subject (Bob) is able to log in synchronously to consent to sharing of the claim? It could work, but it's very point-to-point. This means that Bob may have to log in n times to n claims hosts, where the claims catalog provider/discovery service (AM2) had indicated that the way to satisfy AM1's request for claims needs lots of claims from lots of hosts.

If we wanted to allow AM2 to roll up claims from multiple hosts into an aggregation, probably the individual claims would have to be signed by each host and the aggregation would be signed by AM2. George believes the signed-token work in OAuth doesn't quite go far enough to satisfy such a use case because it doesn't have an "issued to" parameter.

Do we need the OAuth token work's encryption stuff? Possibly not yet.

How would shared secrets work? Susan's company has done some work on this, and it's not as straightforward as might be supposed. George observes that OAuth already has a shared-secret model at its core, so leveraging it could make sense for simplifying things. For third-party aggregation, it falls short.

Should we really consider standardizing attribute formats? The ones in the etherpad are just examples, but it's obviously useful to dictate a single answer for how to encode attributes and to, in effect, standardize attribute APIS (so that then you can OAuth-protect or UMA-protect it). OpenID support is a nightmare because it has several conflicting and overlapping definitions.

In addition to the sources mentioned in the etherpad, there are other sources for important attributes that start to get into verified claims:

Ideally, we'd want to point clearly to single sources of attribute definitions rather than repeat all this stuff in a spec.

Paul asks: How do we intend to identify the subject of these claims? The early UMA work (on Claims 2.0) tried to face this, and it was very difficult. How can one party issue a claim about the subject, such that another party can believe that the claim is about the "same subject"? In the non-aggregated point-to-point case that Eve gave above, George believes the trust hinges on the claims catalog provider being correct in sending the requesting party to that specific claims host to log in. Crypto comes into the picture if you have an aggregated end-to-end model, for the subject and for the other entities communicating.

We have a number of design principles and requirements that are going to end up in conflict with each other. Privacy, cryptography, simplicity, etc. We'll have to decide which ones are most "violatable" in each case. In the specific use case of Bob having to share a trusted claim about whether he's "bob@gmail.com" in order to gain access to Alice's online stuff, where an embedded instance of UMA is being leveraged to protect this claim in service of Bob's as a requesting party, Alice's privacy is paramount and his privacy (even as an "embedded authorizing user") is subordinate to the needs of Alice's access control policies.

Can we leverage a person's discoverable public key in having a claims host sign a claim? This is not privacy-preserving because a public key is a global identifier. But it may be necessary to use this mechanism to make the solution minimally simplified.

Domenico comments: A bootstrapping process is necessary to start the chain of trust. This can be done during the registration of each claims host and the claims it represents for this user. With this step Bob is delegating to the claims host the ability to respond to claims requests. Bob's AM (AM2) is in a position to correlate that it's the "same Bob" in all cases. But then AM2 becomes an intermediate requester on Bob's behalf and can see the claims' content. Eve suggests that we need to be careful about naming the "entity roles" that AM2 fills, and not dump it all into an "AM" or "claims catalog provider" role.

Resource reg spec

  • Catalog new issues based on review
  • Try to knock off low-hanging-fruit issues

Lukasz asks: Why do we have actions assigned per resource instead of per host? George's expectation was that the host is defining what actions are available for a given resource, and it's authoritative for this. There's no way for the AM to create another available action for any one resource. The way the spec sets things up, actions are defined globally but are referenced on a per-resource-set basis. This allows different resource sets to have their available actions differ.

Conformance testing questions

  • Review issues that are blocking conformance test plan completion

Cordny presents: The test cases 1, 2, and 3 correspond to the UMA core spec steps. The test cases are in logical pseudocode. The branches reflect choice points in the protocol flow. They sometimes have names, like "happy flow" for a success result.

Let's focus today on the conformance issues related to how the core spec and the rreg spec interact. Eve throws out a strawman: What if we REQUIRE the host to register at least one resource set and at least one available action that this resource set references?

The alternative might be to have a default/implicit "all"/"all" scope (or "none"/"none"!?) that is applied before the point when the host has registered anything. At the last F2F, we discussed reasons why entirely public and entirely private resources might want to be managed by an AM, and it's really dependent on the nature of the host, the resources, the user, etc. The authorizing user might have a default policy that gets mapped to registered resources and actions from particular (or all) hosts – but we think those resources and actions have to be explicitly registered. And the host has the right to self-manage access to its resources, so this right has to be preserved. So we're agreed to take this approach for now. This will start to give Cordny the information he needs to flesh out this portion of the test cases.

Next Meetings

  • WG telecon on Thursday, 16 Dec 2010, at 9-10:30am PT (time chart)
  • WG telecon on Wednesday, 22 Dec 2010, at 9-10:30am PT (time chart)