UMA telecon 2012-07-12

Owned by Former user (Deleted)
Last updated: Jul 12, 2012

UMA telecon 2012-07-12

Date and Time

    • WG telecon on Thursday, 12 July 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-06-21 and 2012-06-28 meetings
  • August IETF 84 meeting: anyone attending?
  • Feature test progress
  • Implementation progress
  • Spec/issues review
    • #56: Standardized scope descriptions for well-known APIs
      • See Eve's email showing an example that applies to UMA itself
    • #58: Specify how to write UMA profiles
    • Which additional UMA token profiles are most needed next? (related to issues #14, #24, #50, #51)
      • See Eve's email discussing the landscape of options
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes of 2012-06-21 and 2012-06-28 meetings

Minutes of 2012-06-21 and 2012-06-28 meetings APPROVED.

August IETF 84 meeting: anyone attending?

Possibly Eve and possibly Thomas (we're guessing).

Feature test progress

Eve and Trey, along with new participant Martin from UnboundID, met last week. The SMART team has registered themselves as a participant and also registered their three solutions. Fraunhofer hasn't registered itself or its solution yet. Eve will try and revise the feature tests and get them on the wiki for next week.

Implementation progress

Fraunhofer AISEC has open-sourced its UMA implementation under Apache Amber. Fraunhofer consulted with the Apace community, and concluded that the Amber project is the best fit for their UMA implementation. They are planning to use UMA as the base for a project that involves downloading an app to share personal info with friends. Alam will share more news by the end of this month.

The development on the SMART side is progressing. No news on the open-sourcing.

#56: Standardized scope descriptions for well-known APIs

See Eve's email showing an example that applies to UMA itself.

Note that OAuth went for simple strings vs. URIs to avoid length problems in the case of involving a browser.

What's the value of doing this in pure OAuth use cases, and other non-UMA use cases such as OpenID Connect? Nothing overt; the value is just pedagogical.

Should we define sample scope descriptions for OpenID Connect? This seems like a good idea. They have reserved keywords for natively defined scopes and otherwise allow URLs for scopes.

What about security, since we're requiring the AM to dereference the host's supplied scopes? We could just enable JWS, which includes a header that says where to get the key so as to verify the signature. This would just prove that it's self-contained and hasn't been touched/tampered with by anyone other than the issuer. To go farther, could we suggest that the domain of the host and the domain of the JSON doc match? Maybe we could reuse some language from the "request object" specification portion of OpenID Connect. Or we could specify other HTTP-level types of things like S/MIME.

AI: George: Create sample OpenID Connect scopes.

#58: Specify how to write UMA profiles

Peter had found SAML's guidelines for writing profiles enormously helpful, so let's base our spec advice on that example, and make it normative. We'll need two sections: general profiles and token profiles. Domenico notes that deployers might need profiles for different sharing constellations. Eve agreed and noted that something like an e-citizen use case might want a profile that requires the authorization code flow. Peter observes that geographic/jurisdictional considerations could affect profiles, for example the age of consent in different countries. This brings in the idea of how the Binding Obligations doc can be incorporated into a larger agreement or legal framework.

AI: Thomas: Create candidate spec text about UMA profiles and UMA token profiles.

Which additional UMA token profiles are most needed next? (related to issues #14, #24, #50, #51)

See Eve's email discussing the landscape of options.

Today we do option 1 (specifically, 1a) according to Eve's earlier email. Does option 3 (giving claims to the host in the token) potentially expose the host inappropriately to user claims? Yes, particularly in the case where the requesting party isn't the authorizing party. That would have to be dealt with in the Binding Obligations, if it's even allowed at all. Some folks have already expressed interest in option 2 (giving just an authorization decision to the host in the token), so we should probably work on that one next.

Attendees

As of 12 Jul 2012 (pre-meeting), quorum is 6 of 11.

Voting participants:

  1. Alam (becoming voting this time)
  2. Abeti, Riccardo
  3. Catalano, Domenico
  4. D'Agostino, Salvatore
  5. Fletcher, George
  6. Machulak, Maciej
  7. Maler, Eve
  8. Moren, Lukasz
    Szpot, Jacek

Non-voting participants:

  • Cox, Kevin
  • Davis, Peter (soon to become voting)
  • Hughes, Andrew

Regrets:

  • Hardjono, Thomas
  • Drake, Trey

Next Meetings

  • WG telecon on Thursday, 19 July 2012, at 9am PT (time chart)
  • WG telecon on Thursday, 26 July 2012, at 9am PT (time chart)

Â