https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#am-endpoints We decided in yesterday's call to remove the following properties entirely: *pat_profiles_supported*: TO BE REMOVED in rev 07 *rpt_profiles_supported*: TO BE REMOVED in rev 07 We agreed to discuss what to do about the others, on the principle that defining extensibility points when there's only a single exemplar of a usage of the extensibility point is not a good enough rationale for it. *pat_grant_types_supported*: REMOVE OR KEEP? The OAuth Metadata spec https://tools.ietf.org/html/draft-ietf-oauth-discovery-04#section-2 defines an optional grant_types_supported property. We could say that since a PAT is an ordinary OAuth access token, an UMA AS could simply leverage OAuth AS metadata in the usual way and use this property if it wants to (or not say anything at all, since a PAT is 100% purebred OAuth). *Proposal*: Remove. *claim_token_profiles_supported*: REMOVE OR KEEP? This ties to Sec 3.6.1 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#claim-push. We don't define any claim token profiles ourselves, but -- perhaps dangerously -- provide an example of a format called " http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken", by which we loosely meant OIDC built-in plus extension claims. I know several UMA implementations have included this, but I have no idea if they're interoperable. *Proposal*: Keep, but seriously clean up the language around HybridIDToken, and possibly supply a couple of real profiles for the obvious ID tokens people would want (canvass implementers for interest in which kinds of tokens). *uma_profiles_supported*: REMOVE OR KEEP? This ties to both Sec 5 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#comms-profile... (*extensibility* profiles already defined in the spec, with the intention that various communities would hopefully define *extension* profiles on top of them) and Sec 6 (UMA's framework for third parties to build profiles and extensions, based on SAML's similar one). Since the AS has config data, and right now the RS and client don't really (I guess there's software statements too), there's a bit of a hole regarding what profiles and extensions can formally be expressed. *Proposal*: Keep. Canvass implementers for interest in the extensibility profiles. Ensure that Sec 6 fully includes extensions as well as profiles in its language. Consider whether there's anything to say about software statements, and anything forward-looking to add about other "authorization metadata/config framework" efforts going on. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl