UMA telecon 2010-07-15

Owned by Former user (Deleted)
Last updated: Jul 17, 2010 by Former user (Deleted)Version comment
5 min read

UMA telecon 2010-07-15

Date and Time

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

Agenda

Attendees

As of 3 Jun 2010 (post-meeting), quorum is 6 of 10.

  1. Adams, Trent
  2. Catalano, Domenico
  3. Fletcher, George
  4. Machulak, Maciej
  5. Moren, Lukasz
  6. Scholz, Christian

Non-voting participants:

  • Nat Sakimura
  • Ann Ticktin

Minutes

IRC Channel Reminder

  • Reminder of IRC channel: #umawg on irc.freenode.net (web interface)

Roll call

Quorum was achieved.

Approve minutes of 2010-07-08 meeting

Minutes of 2010-07-08 meeting APPROVED.

Action item review

  • 2009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios document. Not sure what is the status of this one.
  • 2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user stories.
  • 2010-06-17-1 Christian, Eve Open Work on the conversion of the core spec and the dynamic registration spec to xml2rfc. Dynamic registration done so far. Christian will work to complete this AI.
  • 2010-7-01-1 Christian Open Sketch a new version of push+pull RRAPI, taking into account the 2010-07-01 discussion, the Artifact Binding, and the SMART resource registration writeup. In progress; hopefully to be largely completed shortly.
  • 2010-07-08-1 Maciej, Eve Open Figure out strategy for announcing opportunity to sign up to become SMART UX testers. Completed. Check out here
  • 2010-07-08-2 Christian Open Automate the process of generating viewable HTML and TXT from the xml2rfc files and put them in a consistent place. In progress.

Upcoming UMA talks

Eve will have a presentation about User-Managed Access at Cloud Identity Summit next week.

SMART user testing info

The SMART project has started User Experience evaluation study. Checkout details here. Participants are very welcome!

Working drafts

Christian copied SMART specification with some smaller changes to the XML format - recreating diagrams. In the “Dynamic binding” specification he will move section 3.1 to section TODO - it’s not well-suited to the OAuth. Section 3.2 is mostly based on the specification from the SMART team.

The group discusses what is necessary within the specification and what is optional. In Push and Pull models - can there be additional information included that describes the host? We should define a set of properties that need to be included and possible extensions.

George talks about the OAuth and assertion profile - how it handles extensions.

Pull method can be easier in maintaining all the trust bits. The push model is like in OpenID, anyone who shows up can be an RP. Not a lot of validation. In higher value transactions you want to know all the parties involved in the transactions. Can we therefore apply the trust model to the push model in the Dynamic Binding specification?

We should try to define extensions points.

Do we really need two flows or is just pull sufficient. What information does the server need. Maybe the client should be able to discover that information?
George - in OAuth you can add parameters. This is the place then to provide extensions mechanism.
An authorization server may require additional information than this specified in the documentation. Why do we need additional information? We should move this out to extensions specification (Christian). Christian - separate section about extensibility. More formalized.
OAuth and the trust framework may not appear in any form (G).
When you discover a registration endpoint you can discover what properties are required.

Client-secret - browser based applications should be allowed for dynamic binding. Browser based apps are the only apps not to use CLIENT_SECRET - javascript-based applications.

For discovery - these apps should have a constant Website (like in the iPhone model) to provide information about themselves. But what if you create a new iPhone app that should use a different client id and client secret (there’s already a website).

There’s no way to bind the XRD to the client. Clients can then use publicly available servers. The Authorization Server cannot check whether the XRD is correct for the client. The trust framework should be applied to that then. The client application must have a website even if this app is not web-based.

Registration endpoint property in XRD at the AS could provide information which model should be used by the client. But now the specification defines that both must be supported by the AS and only one should be supported by the client. We should then decide which one to support.

We need to collect the reasons for these two methods and see if we can get rid of one of them or to merge them.

URL is actually required in the push model only for the user display - the user should know what is connecting to the AM. If push alone is sufficient - how then the trust layer on top would look like?

Domenico added the trust framework to the push model (mailing list). If we want to maintain trust relationship with the client - then we need information about the client and the LoA. The AS should be able to verify that information at a trust framework provider.

George - IdP is registering with the AS. The special case defined in email by Domenico - the pull model could solve that by itself. The URL could be checked by the AS.

Christian - therefore maybe its good to merge both models (push and pull). In this specific case that Domenico sent to the list, information does not have to be in the client registration model - at least in the pull case.

In the push model - the client can also push the XRD. But there needs to be some sort of signing mechanism so that its trusted. The document should point to some information regarding trust and both models should allow trust to be incorporated.

In the pull model - the URL should point to the host or to the actual XRD file (or a file containing information about the client)? Are there any advantages of just having a URL to a host and not direct link to a file?

Dynamically changing info - Is the name and the description always the same that the application provides?

Having a URL that points to a file - not a host-meta particularly -this would save a lot bunch of steps - this would just point to the XRD file, for example. In the XRD, properties should be nested instead of being flat.

The client registration response is the same as in the push model - client id and client secret

Model errors as OAuth 2 is doing - so we either go with 400 or with 404. We should provide the list of possible errors.

Would be great to provide an example of signing requests for push / pull cases. We should discuss advantages and disadvantages of push and pull. Christian has collected some of these but would like to collect more.

What with the propagation requirement that is in the specification? Is that really required?

For iPhone you must have a website. In Facebook you can even register a localhost. Developers must have an external website when developing apps for phones (not sure if this is in Android, though).

Prioritize other work

The encourage group members to actively participate on the mailing list and on the IRC channel - discussions during conference calls are really good but are insufficient.

Next Meetings

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