> 1) what metadata you associate with a profile today
Generally, anything that we'd want to change in large swaths across a
cohort of clients, so, things like the allowed token_endpoint_auth_method,
enforcement of PKCE, etc.
> 2) how much of that metadata you think belongs in a standardized
structure vs. vendor-specific fields
Certainly, things like the token_endpoint_auth_method, enabled_grants,
pkce_required - common sense things. There should be a provisio for
"client_metadata", such that vendors may encapsulate their specific
behavioural modifiers in a well-defined area. We're certainly coalescing
around the need for such a metadata map, given our ownership hierarchy. I'd
love to know what others think, especially considering how rightfully
averse this wg has been around the fields that define a client; usually,
specs point to requisite behaviours and leave the implementation as an
exercise to the vendor :)
> 3) whether the “profile owner” concept generalizes well across ecosystems
It does generalize well for us, wherein we have multiple products across
different lines of business: Confluence mobile or Trello powerups - each
calling out a clear owner + use-case. Perhaps there's a case for a
"profile" field with a URN
value, urn:ietf:params:oauth:client:profile-name:${profileName}, where
you'd end up with something like,
urn:ietf:params:oauth:client:profile-name:bing.mobile
> Also, when you mentioned CIMD's lack of unique registration, were you
referring to not being able to uniquely register agent instances, or to
something else?
Yeah, essentially. A client ID is an identifier by which the A/S can "know"
the caller, but a URL is owned by the domain registrant, and the TLS
certificate information might or might not agree with that WHOIS
information; moreover, we're putting the burden of hosting a TLS endpoint
upon some external caller - Let's Encrypt / ACME makes this easier, but
still... Then there's the question of an A/S punching out to fetch an
untrusted document, but I totally understand that this may already be
happening with private-key-jwt clients pointing to a JWKS, but this is a
whole other scale of outbound calls.
Cheers!
Michael
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
