UMA telecon 2013-06-27

Owned by Eve Maler
Last updated: Jun 30, 2013

UMA telecon 2013-06-27

Date and Time

  • All-hands meeting on Thursday, June 27, at 9am PT (time chart)
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • (Get on http://join.me/xmlgrrljm)
  • Roll call
  • Approve minutes of UMA telecon 2013-05-30, and read into today's minutes the notes from UMA telecon 2013-06-06, UMA telecon 2013-06-13, and UMA telecon 2013-06-20
  • Quick check-in on the idea of lengthening meetings when they start up again on July 18
  • Quick review of CIS and interop plans
  • Discuss latest draft: okay to submit to IETF? (will be uploaded to here)
  • Presentation/discussion on XACML and interoperable scopes with Hal Lockhart
  • GPII/Scalable Privacy update and demo
  • Presentation/discussion on Cloud Identity's proactive PAT issuance solution
  • Review of any action items we didn't already cover
  • If time: decide on issue 83
  • AOB

Minutes

Roll call

Quorum was reached.

Ron Turner has specialties these days in IAM, security, and XACML.

Approve minutes

MOTION: Approve minutes of UMA telecon 2013-05-30, and read into today's minutes the notes from UMA telecon 2013-06-06, UMA telecon 2013-06-13, and UMA telecon 2013-06-20. APPROVED by unanimous consent.

Quick check-in on the idea of lengthening meetings when they start up again on July 18

Andrew's Thursdays don't allow him to join. Eve has a conflict on July 25; Maciej will run the call. It seems we don't have consensus to lengthen the meetings at this time.

Quick review of CIS and interop plans

We're having a meeting July 9, at least in the morning and possibly some of the afternoon, at CIS. Contact Eve for details.

Presentation/discussion on XACML and interoperable scopes with Hal Lockhart

The slides have been uploaded to the wiki, and he has a white paper here. Scope is not well defined by RFC 6749. Hal distinguishes between requested and issued scope. The AS should be able to compute scope based on the RO, client, and potentially requested scope. RS should be able to interpret scope based on info it has. He proposes calling a set of attributes a Situation. He proposes including an XACML decision request in the scope request. The PDP obtains the applicable policies by ID; they could be cached. He proposes creating "decapitated" policies that allow the subject to be a kind of plug-in constant value.

Discussion: Eve recommends reading the UMA proposal for OAuth resource set registration, which does a lot of work around making AS/RS communication loosely coupled and provides a way to define standardized scopes, meeting (she believes) the list of scope requirements listed. The entire scope<->policy nexus is exactly where she believes we could usefully explore an UMA/XACML connection, profiling, or whatever.

In this proposal, there are attributes feeding into the policy expression. Is getting the attribute values the responsibility of the party calling the PDP? 

Also see Eve's previous presentation to the XACML TC.

AI: Eve and Domenico and Domenic: Do close reading of Hal's white paper with UMA in mind. (Hal will do the converse!)

GPII/Scalable Privacy update and demo

We can keep track of this progress on the project's wiki.

Presentation/discussion on Cloud Identity's proactive PAT issuance solution

Maciej demonstrated SmartPDS.appspot.com. He showed two things: (1) signing in the user to an authorization server during the sign-in process to the SmartPDS resource server, and (2) allowing SmartPDS to obtain a PAT during that authentication process. The first step is for the new user to register for/sign in initially to the app through the Google IdP, which generates an OAuth-based response coming from Google. The redirect back to the SmartPDS relying party gets intermediately redirected through a proxy, which checks before sending the user back to SmartPDS whether SmartPDS is UMA-enabled. it signs in the user to the SmartAM authorization server, which generates the PAT on the back end. SmartPDS can then execute a simple call to the SmartPDS Connect API (basically an enhanced OpenID Connect-based API) to obtain the PAT so that the SmartPDS RS and AS can get easily introduced. SmartPDS's knowledge of which AS to use is buried in the SmartPDS app's configuration process; it happens only to work with SmartAM. Alternatively, the user could have been asked to choose any suitable AS at the time of registration to SmartPDS.

Eve believes the "automatic PAT issuance" use case will be particularly valuable in sector-specific use cases where a trust framework/broker situation requires use of a single AS (or short list of them). Is it worth profiling this formally? Yes, seemingly so, since this isn't a vanilla OAuth flow but an OpenID Connect-enhanced one. This logic would apply identically to the AAT issuance process and the requesting party, vs. the PAT issuance process and the resource owner. Essentially, since OpenID Connect-format user data is available through the federated login to the app (which may be an RS), this data can be leveraged for efficient PAT/AAT issuance.

See this github page for an example of the enhanced PAT request call to the Connect API.

AI: Maciej: Write up candidate spec/profile text to describe what's being done beyond current UMA spec text.

Attendees

As of 26 June 2013, quorum is 6 of 11.

  1. Mark Dobrinic
  2. Eve Maler
  3. Maciej Machulak
  4. Keith Hazelton
  5. Domenico Catalano
  6. Andrew Hughes

Non-voting participants:

  • Ron Turner
  • Domenic DiLullo

Guests:

  • Hal Lockhart

Regrets:

  • George Fletcher
  • Thomas Hardjono
  • Dave Coxe

Next Meetings

  • (No meeting Thursday, July 4 because of the US holiday) 
  • No meeting – vs. potential F2F/summit during CIS – on Thursday, July 11? - Eve, Andrew, George, are attending CIS
  • Focus meeting on Thursday, July 18, at 9am PT (time chart) – 60 or 90 minutes?
  • All-hands meeting on Thursday, July 25, at 9am PT (time chart) – 60 or 90 minutes?

Â