Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Roll call
  • Approve minutes of UMA telecon 2016-10-13, 2016-11-03 
  • Logistics for upcoming meetings (calendar) and 2016 roadmap check-in
    • Next week: WG meeting on Fri Nov 18 at 9am PT after legal call instead of Thu Nov 17
    • Week after: no WG or legal meeting due to US holiday
  • Work on UMA.next issues – Core is up to 06 and should be up to 07 well before the meeting – please review changes ahead of time if possible
    • The following changes affect syntax:
      • Removed config data to declare pat and rpt profiles supported (as agreed last time)
      • requesting party claims endpoint --> claims interaction endpoint (language that affects syntax in endpoint config data )
      • resource set --> resource (language that affects syntax in endpoint config data and token introspection returned object format)
      • New AS-to-client invalid_scope error (because a client can now ask for scopes)
      • RPT token profiling has been properly removed now (means token introspection, if used, requires using the permissions structure)
        • "Authorization data" flexibility can only be added, not substituted – is this OK?
        • Do we need to reconsider the last bullet in Security Considerations Sec 7.1.1 re PoP/HoK?
      To discuss specifically this time:
      • 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?
      • pat_grant_types_supported: My proposal was to remove it. Any further discussion?
      • 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?
      • Is the (client) registration endpoint's name correct according to the naming pattern used in UMA, and also OAuth and OIDC?
  • See the latest swimlane
  • AOB

...