UMA telecon 2009-12-17

Date and Time

• Day: Thursday, 17 Dec 2009
• Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
• Dial-In:
  • Skype: +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Attendees

As of 10 Dec 2009 (pre-meeting), quorum was 10 of 19.

Voting participants:

1. Adams, Trent
2. Akram, Hasan
3. Bryan, Paul
4. Catalano, Domenico
5. Davis, Peter
6. Fletcher, George
7. Holodnik, Tom
8. Lizar, Mark
9. Machulak, Maciej
10. McIntosh, Michael
11. Maler, Eve
12. Scholz, Christian
13. Smith, Bill

Guests:

• Joni Brennan (staff)

Regrets:

• David Chadwick
• Christian Scholz

Agenda

• Administrative
  • Roll call
  • Approve minutes of UMA F2F 2009-12-10
  • Action item review
  • Review telecon schedule and F2F opportunities in 2010
• Review and approve/defer/reject scenarios and use cases
  • E-commerce
  • Personal loan
• Claims spec review
• AOB

Minutes

Administrative

Roll call

Quorum reached.

Approve minutes of UMA F2F 2009-12-10

Minutes of UMA telecon 2009-12-10 APPROVED.

Action item review

Hasan closed his AIs. Eve closed her e-commerce-related ones.

Webinar idea: let's plan on January 29 (time slot to be determined). We can record a WebEx session (or similar) for later playback by people who couldn't attend; Kantara can offer us WebEx facilities if that's what we decide to do.

Review telecon schedule and F2F opportunities in 2010

Let's keep the Thursday 90-minute slot for telecons.

Update on EIC 2010: We are considering having a 4-hour (half-day) meeting colocated with EIC; could be a public meeting or a meeting that requires attendees to have signed the GPA. Hasan is the main contact for this.

The March F2F in Oregon is coming up; registration is open, so please sign up.

Review and approve/defer/reject scenarios and use cases

E-commerce

We worked through the email thread containing Paul's comments and Eve's responses.

Personal RFP discussion: Does this idea need a broker? Probably it will involve one in practice, but it need not. You could, e.g., post a PRFP to your "host" of such things and then tweet its availability with a certain hashtag.

Using OAuth authorization vs. needing something heavier: Paul is imagining a kind of "hybrid OAuth-to-UMA" scenario, where, since the user is already present, you don't need to wait for some sort of out-of-band consent given later by the authorizing user (while the same person waits impatiently at the requester app for the "pending" icon to finish!).

So this has protocol implications. In the case where the requesting party is the same person as the authorizing user, can we optimize by literally using OAuth to allow for in-band user consent? Note that this scenario turns the host site into a kind of "attribute service"; an OAuth-protected attribute service is something that isn't really seen in the wild today, though a lot of the pieces are there to make it possible. We are trying to solve a larger problem (externalized user-driven authorization) that happens to include this smaller problem space.

In the current protocol flow, the requester has to go through a process of trying to get the AM's authorization state to change to "authorized", after which it can go back to the host (and the host goes and asks for the authorization decision itself). George: It's overkill to use OAuth among the user/requester/AM for this purpose. Paul: Agree; it's overkill to do anything other than redirecting the user to log in over at the AM to give her approval. George: The Portable Contacts API has a concept of "me", which is perhaps another way of getting what we want here.

Eve: This is an important scenario to solve, and was the original motivation for ProtectServe. If the process of filling in account registration data "by reference" is more painful than filling it in "by value", we won't have solved anything, since users won't use it. George: PoCo endpoints might help, and also form-fill technology might help. If the AM is an aggregator for the PoCo endpoint, certain things could be optimized. Christian: Once again this is sounding like the Distributed Services scenario.

Eve needs to edit the scenario to:

• Discuss machine identification more intelligently
• Reflect what "issuing" a personal RFP might involve
• Add a recognition that there are UX/protocol issues to consider in approving the requester's request
• Deal with any other items raised in the email thread

...and send out a link to the change-tracking version of the scenario for later discussion.

Personal loan

Domenico sent out a slide deck explaining the scenario.

The "Authorization/Approval" mentioned on slide 6 means the approval of the loan, not user-managed authorization/approval of data sharing.

George: How does the interaction get kicked off? Does it look like the e-commerce scenario? Domenico: Yes, it might. Eve: It could use a variety of initiation styles; perhaps there could be a "resource discovery service" or catalog employed. Tom: There are regulatory implications here, e.g., bank regulations, that may impact claims exchange. In the e-commerce scenario, it's assumed that all the parties are willing to deal with each other. In this scenario, there may be serious constraints under which they're willing to connect.

Eve: Today, there are companies that specialize in verifying employment on behalf of the real employers. So this function is outsourced, and employer-verifier interactions take place over some web services interface. So this looks a bit like our Requester Delegation situation except that it's a "delegated host".

Tom: We have to guard against a bewildering user experience; even if the protocol works, the presentation of the opportunities for consent needs to work. Eve: Agreed. In addition, she believes that the ability to set policy and audit sharing, in the confidence that it will work right, saves the user from a lot of real-time confusing experiences they should never have had in the first place. Tom: So if it's a precondition that the user has to pre-register with all the hosts in this scenario, what does it look like for the user to pre-register some host with which they normally don't interact a lot (like an employment verifier)? Eve: Maybe this is another distinctive aspect of this scenario; some of the parties, like the employment verifier, don't exist to give the authorizing user a great online experience.

Tom: The presumption in this scenario so far is that it's a "full-blown site". What about making payments through a kiosk or payment terminal? Eve: Is this in our scope for UMA V1? She'd like to assume that, even though the user might be using something other than a COTS browser, the site he's interacting with is a full-blown site.

Eve: Note that the high value of the data comes from the very fact that it's coming from the various hosts. In essence, they are recognized issuers of important data ("claims", if you will), and the ability to connect with these specific hosts is a kind of verification of the data. Domenico: Yes, this is part of the general trust management problem. Paul: This dovetails with his latest work on claims. How do you prove you're the subject of a claim? In this way, PKI is the biometrics of the 'net!

Tom moves, and Bill seconds, a motion to approve the personal loan scenario. APPROVED.

Claims spec review

Paul has revised the overall protocol flow to include claims handling (the sending of claim requests and the attempted satisfaction of those requests).

If something is already checking a resource at the AM periodically because it's waiting for a state change, how much callback sophistication do we really need to provide? Eve: In general, less sophistication is better. Perhaps float this question on the list? Paul: Will do.

How should we handle the situation when a requester supplies claims that don't, for whatever reason, satisfy the AM's "claims-required" needs? Should the AM return something that's human-readable but not machine-readable? Eve: Can't the AM just keep sending back "claims-required" messages as long as the requester hasn't yet supplied whatever is necessary? Perhaps such messages always come with a human-readable equivalent to help in debugging. If the requester can't live up to the claims requested, maybe it would simply walk away at some point. Tom: E.g., if the AM needs to know that the requester is a licensed mortgage broker in the state of Nevada, and that claim can't be provided, what happens? The implications are important to figure out. Bill: If you want real complexity, look at claims that involve alcohol shipping between U.S. states! Paul: Does the AM need to say, at some point, that "these nine claims satisfied my request for claims, but this one didn't"? Eve: Suggests that he ask on the list.

New AIs

Next Meeting: UMA telecon 2010-01-07

• Day: Thursday, 7 Jan 2010
• Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
• Dial-In:
  • Skype: +9900827042954214
  • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)