Open ID Connect Metadata ????

Session Topic: OpenID Connect and Metadata? (T4I)

Conveners: RL "Bob" Morgan and John Bradley

Note-Taker(s): RL "Bob" Morgan

Tags for the session - technology discussed/ideas considered: OpenID Connect, SAML, metadata, OAuth, trusted third parties

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

RLBob's intro: Metadata use in Higher-Ed and Research SAML federations began as a way of collecting, validating, and distributing endpoint (IdP/RP) data for communities of interest. Experience has shown that the essential value is in the trusted third parties (federation operators, aka trust framework providers, TFPs) making statements about sites and orgs that can be securely consumed by participating services to add value to their federated interactions. Statement examples are "this is a research SP", "this is an IdP in the UC system", as well as names, URLs, keys, etc. OpenID Connect has dynamic registration and endpoint discovery baked into it, but communities still have requirements for TFPs making statements that can be used in discovery, validation, and trust management by IdPs and RPs. Can we find a way to add these features to OpenID Connect?

Possible things to do were discussed:

1. an OIDC profile for a site using standard OIDC discovery and dyn-reg trust mgt, then doing 3rd-party lookup as another processing step might need to distinguish between self-asserted and TTP-managed info elements

2. an OIDC profile for reg/discovey in the style R&HE federations do it today: ignore dynamic reg and discovery and just use TTP for site info this would require #3 ...

3. profile for defining OIDC/OAuth endpoints in SAML metadata format:  this would be canonical version, map/export into JSON as needed?

4. OIDC discovery info is a JSON object, could be transferred as is,  but signing implies base64ing the data, so makes it unreadable; and multi-entity collections in JSON (equivalent to SAML MD EntitiesDescriptor element) would be problematic so ... use XML format for all that, and JSONize when needed?

discussion: is the OIDF OpenID Connect WG interested in any of this? JB: maybe, probably, constituency has to show up

Kantara Federation Interop WG needs this, mainly motivated by US Gov use cases

OIX Attribute Exchange WG motivates TTPs and certification for enabling RPs to find/trust sources of attributes in an ecosystem, so needs metadata. Fully supporting this use would require metadata extensions that do not yet exist ...

Since some of this potential metadata is OAuth-specific, does this imply that work should be done in the context of the IETF OAuth WG, which is rechartering? Mike Jones: it's probably 70% OIDC-specific, so probably can be done all in the OIDF