Page Comparison

...

• Roll call
• Approve minutes of UMA telecon 2016-11-10 
• Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
  • Next week: no WG or legal meeting due to US holiday
  • Week after: normal WG meeting on Dec 1
  • Week after that: Eve unavailable on Thu/Fri...
• Work on UMA.next issues – Core is up to 07 (soon 08) and RReg is up to 01 – please review changes ahead of time if possible
  • Besides agreed and expected changes, main changes are:
    • Removed pat_grant_types_supported per proposal
    • "protection API token" --> "protection API access token"
    • "permission registration --> "permission request" (rhetorical and syntax)
    • "permission_scopes" --> "resource_scopes"
    • "resource set reg" --> "resource reg" (rhetorical and syntax) in RReg spec
    • Introduction text in Core (incomplete) – Please especially review
  • To discuss specifically this time:
    • Briefly review Introduction and plan to include high-level diagram
    • Discuss "token profiling" proposal to:
      
      • Make token introspection permissions structure optional
      • Require its array to contain one or more values
      • Require AS to support token introspection
      • Require AS to support permissions structure
      • Recommend development of extensions for alternative introspection structures
    • Even if token introspection isn’t used, can/should we require the ability for a locally validatable RPT to operate at a “permissions” grain somehow?

    • Need to say something about RReg taking place in the context of a resource owner? Is it always done in that context? Doesn't it depend on the RReg security mechanism used?

    • Set math: See 9-29 and 10-6, and the email thread – including...
      
      • What scopes should the client ask for, and why? (E.g., least-privilege rationale.) What should the mechanism be for asking for scopes for specific protected resources?
      • What permissions should the RS request on behalf of the client, and why?
    • claim_token_profiles_supported: My proposal was to keep this profiling mechanism, but clean it up and provide two actual profiles or at least credible examples, say, for OIDC ID tokens and SAML assertions. Discussion?
    • uma_profiles_supported: My proposal was to keep this profiling mechanism, but figure out seriously if the extensibility profiles are doing the right job, and include credible examples of extensions and not just extensibility profiles. Discussion?
    • Is step-up auth the way it was conceived in UMA1 hunky dory according to the claims collection mechanism in UMA2?
    • Need to have IANA registry entries for both old uma-configuration and uma2-configuration?
    • Shoebox endpoint
    • Claims hashing
• See the latest swimlane
• AOB

...