UMA telecon 2011-06-23

Owned by Former user (Deleted)
Last updated: Jun 24, 2011 by Former user (Deleted)Version comment
6 min read

UMA telecon 2011-06-23

Date and Time

  • WG telecon on Thursday, 23 Jun 2011, at 9-10:30am PT (time chart) - Eve regrets; Maciej to chair and take minutes
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

  • Roll call
  • Approve minutes of 2011-06-16 meeting
  • Action item review
  • Schedule gut check
    • Identify one last ad hoc meeting date for next week?
    • Publicity approach? (Susan)
  • Discuss discovery and hData implications for UMA ('pad)
  • Protocol revisions: core spec
    • Open issues
    • Fill in missing bits
    • Interface between UMA and trusted claims
  • AOB

Attendees

As of 2 Jun 2011 (pre-mtg), quorum is 6 of 11.

  1. Mohammad, Alam
  2. Catalano, Domenico
  3. D'Agostino, Salvatore
  4. Fletcher, George
  5. Hardjono, Thomas
  6. Machulak, Maciej
  7. Maler, Eve
  8. Moren, Lukasz
  9. Morrow, Susan
  10. Wolniak, Maciej

Non-voting:

  • John Bradley
  • Kevin Cox

Regrets:

  • Frank Wray

Minutes

New AI summary

Roll call

Quorum was reached.

Approve minutes of 2011-06-16 meeting

Minutes of 2011-06-16 meeting were APPROVED.

Action item review

  • 2010-11-18-4 Eve Open Capture new user stories in the wiki.
  • 2011-04-07-2 Frank, Kirk Open Match constellations to scoped access diagrams to see what happens.
  • 2011-04-14-1 Maciej, Alam Open Build list of FAQs (both questions and candidate answers) on the wiki.
  • 2011-05-12-1 Eve Open Check out the possibility of running a new UMA webinar. Now closed. Webinar will be July 15.
  • 2011-06-02-1 Thomas Open Recommend times to do a WebEx SMARTam demo with the UMA WG members. Now closed. Let's plan to do a dry run on Monday July 11 at 9am PT using Thomas's WebEx.

Sal and Eve are planning to create a few slides he can present at next week's NSTIC workshop. He and Mark Lizar got the idea to ensure UMA gets some appropriate attention there. There's also a new Kantara NSTIC Discussion Group that has started. Its first call is tomorrow.

Schedule gut check

  • Identify one last ad hoc meeting date for next week?

Let's meet next Monday, June 27, at 9am PT. Eve will ask Anna to set up a calendar entry and advertise the meeting to our list.

  • Publicity approach? (Susan)

Susan is working on a social media-enabled PR/marketing plan for our activities over the next month. She'll work on this with Dervla, including a press release.

Discuss discovery and hData implications for UMA ('pad)

John comments that the Simple Web Discovery protocol gives simple, unconstrained access to a discovery service; probably this wouldn't be suitable for hData. OpenID Connect gets more sophisticated, helping to give back a claim to a deserving requester by giving an access token to get into that service. Would an hData "Discovery and Authorization Service" (DAS) want to be OpenID Connect-enabled in order to get the extra layer of permission that it offers? We had sketched a potential scenario for applying UMA to hData where both potential requesters could approach the DAS to get the locations of health data, and also potential hosts could approach the DAS to try and put their own metadata into the DAS. In that latter case, it's more like an "introduction service".

We discuss the issues raised during the earlier ad hoc call. Thomas comments on every issue and discusses what has been already addressed and has changed within the specification:

  • We should make it clear that the personal datastore example is just an example, and point out to the scenarios, user stories, etc. documents.

-> DONE. Paragraph fixed and pointer added to UMA use-cases doc.

  • We should reorganize the spec so that phase 1 comes first once again. Should we also move the resource registration API forward? Maciej has a mild preference for moving it forward as well. As long as we're going to keep it in the core spec for now, it should be moved forward. (issue discussed on an ad hoc call)

-----------------

  • We should incorporate the ASCII art in the introduction. Her most recent email to the list has the latest diagram.

-> DONE. Eve's diagram added.

-----------------

  • Add an issue to be resolved post-I-D submission: Should we rhetorically collapse Phases 2 and 3? Comment: This is yet still something we should discuss with the group.

-----------------

Terminology:

  • Extend the definition of "protected resource" to explain that the resource is being policy-protected by the AM.

-> DONE. Added some brief text to explain.

  • Define the special endpoint names in this section. Maybe they could o in a separate list in the section, or in a subsection, so as not to confuse people unduly.

-> DONE. New subsection 1.3 on "End point Names"

1.3. End-Point Names

Host Registration Endpoint
This is the end-point at the AM to which the host register resources which the AM needs to protect.

Protected Resource Endpoint
This is the end-point at the host to which a requester accesses resources.

Token Validation Endpoint
This is the end-point at the AM to which the host submits tokens to be validated by the AM.

Scope Registration Endpoint
This is the end-point at the AM to which the host registers scopes pertaining to resources under the hosts's protection.

Authorization Endpoint
This is the end-point at the AM to which the requester submits requests for authorization tokens.

-----------------

Getting Authorization and Accessing a Resource section (currently 2):

  • Delete the "master interaction" sentence. The "main interaction" concept isn't very helpful, in fact. Thomas will work on wording.

-----------------

Requester's request is ambiguous section (currently 2.1.1):

  • We agree that this section should be within the specification.

-----------------

Requester-AM: Requester Obtains Access Token section (currently 2.2):

  • We need more specificity here. Based on the earlier ad hoc call comments, this will be addressed.

-----------------

Host-AM: Validate Requester's Presented Access Token section (currently 2.3):

  • This should be JSON-encoded rather than URL-encoded, as agreed last week. Maciej will supply the example. The explanatory wording will have to change to match.

Also we discuss the necessity to include the resource set within the validation. This is because otherwise the reply from the AM may contain too much information not necessary for the host to make the access control decision. This is the performance issue, not a security issue. We decide that the Host may send this new parameter optionally. If this parameter is within the request then the AM will reply only with the set of actions that are valid for this particular resource set.

-----------------

  • Let's decide to use "token validation" consistently, instead of using "verification" anywhere.

-> DONE. term "validation" used throughout.

-----------------

  • in Section 2.3 we should use the JSON as the format. How about supporting JSON and JSON Web Token? Should we have any information about that within the specification (George).

----------------
AM returns a token valid response section (currently 2.3.2):

  • We discuss the option of AM returning only the resource set that is relevant for the resource set initially contained within the validation request (see section 2.3).

Host-AM: Register a Requested Scope section (currently 2.4):

  • We need to structure the JSON properly. Maciej will make a suggestion (in progress).
  • We should standardize how we refer to JSON formats throughout. This is to be changed.

Requester-AM: Request Authorization for Scoped Access section (currently 2.5):

  • We shouldn't say specifically that the requester needs to satisfy all the claims, since the AM may have semantics around "optional" or "OR'd" claims. We need to be a little more flexible.
  • This section is also where Domenico's proposal for OpenID Connect wording should go. We're not sure if it will be "mandatory to implement" or just one option of many yet.

----------------------

  • Currently discovery of AM endpoints is given with reference to the Host only. This should be changed as the Requester may also try to discover endpoints at the AM side. We should move text from section (3) Protecting resource to yet another section. We should also not limit ourselves to XRD discovery.
  • Earlier comment from John Bradley - Don’t stick to the Simple Web Discovery only.
  • registration can be done with various means - not only dynamic registration. Should we provide such information within the specification?
  • In Section 3.1.1 we use the term Protection API but do not define it anywhere earlier.
  • 3.1.1 We need to add a host_resource_registration_uri and a host_registration_uri - these are two different endpoints but should be there (currently only the resource registration is present).
  • Open issues
  • Fill in missing bits
  • Interface between UMA and trusted claims

Next Meetings

  • Stay tuned for details of an ad hoc meeting before 30 Jun
  • WG telecon on Thursday, 30 Jun 2011, at 9-10:30am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214