Page Comparison

...

• Thursdays, special meeting times through Feb 9: 8:30-10am PT
  • Skype: +99051000000481 / US +1-805-309-2350 / international lines / web calling interface / code 1782540
  • Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line
  • UMA calendar: http://kantarainitiativekantara.atlassian.orgnet/confluencewiki/display/uma/Calendar

Agenda

• Roll call

• Approve minutes of UMA telecon 2017-01-05 

• UMA V2.0 work

  • 2016 roadmap / GitHub issues for V2.0 (all issues to be kept here for the duration!) / dynamic swimlane
  • Core is up to 11 and RReg is up to 04
    • Issues closed: 108, 234, 249, 261, 262, 268
    • Also tried out Justin's wording for how the AS and client handle invalidating/revoking an old RPT when the AS hands back a new RPT – see Core rev 11 Sec 3.6.6
  • Please see new issues! We'll discuss as necessary next week; please comment online:
    • 271: Add 'description' to scope document
    • 270: Resource Registration Document: 'uri' should be an array / examples
    • 269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document"
  • Issues to discuss and close on this call:
    • 264: Authentication-related error details (quick)
    • 254: Hashed claims discovery (quick)
    • 266: Set math (hopefully we'll have some spec-like wording to guide us further by tomorrow)
    • 256: Naming and concepts, specifically authorization interface vs. UMA grant concept
  • Issues to discuss and hand out assignments for:
    • 256: Naming and concepts, specifically a definition for and handling of the access token/claim token situation
    • 263: Claim token profiling / 119: Create an IANA registry for URIs that stand for claim token formats
    • Shoebox: 246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior / 245: Location Constraints / 224: RS Notifies AS or RO of Access / 63: Audit logs to support legal enforceability / 24: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?
    • 260: Cascading authorization servers
  • Easy issues to close by Tue Jan 7 17 if no comment by then:
    • 256: Naming and concepts, specifically whether to rename PCTs
• AOB

...

Approve minutes of UMA telecon 2017-01-05: APPROVED by unanimous consent.

UMA V2.0 work

Set math: Justin  In his Set Math Discussion email, Justin intended for ROPolicy to stand for the result of AS postprocessing of any policy conditions with which it has been configured. George intended for ROPolicy to stand for policy conditions prior to any AS processing. This may be moot for the math. Justin considered the math to be contextual to the resource set because of his implementation outlook, but George wants to ensure that, if the ROPolicy isn't sufficient to meet the requested policy, need_info (or "worse", definitive failure) is produced.

Eve notes that "RO" policy is really a set of policy conditions that could have come from a collaboration between the RO and the AS; see, e.g., the TTL section.

In George's "attempt at a simple example", Alice has policies that should result in Bob not getting access to download because he's not a family member. Let's think of ROPolicy instead as PolicyResults, (or even AuthorizationProcessResults?) and the value should be just (view, share).

...

AI: Eve: Send out some new cascading authorization server information from VA.

AI: Eve: Send emails for the next issues to discuss.

...

• George
• Justin
• JohnW
• James
• Colin

Regrets:

...