Utkast: Metadata requirements for OAuth 2.0 entities

1. Syfte

Denna specifikation anger krav på federationsmetadata för OAuth 2.0-protokollentiteter inom Samordnad identitet och behörighet.

Kraven syftar till att säkerställa att metadata som behövs för identifiering, teknisk tillit och interoperabilitet uttrycks på ett enhetligt sätt.

Specifikationen omfattar följande protokollentiteter:

Kraven kompletterar OpenID Federation och Ena OAuth 2.0 Interoperability Profile. Den senare anger redan säkerhets- och interoperabilitetskrav för klienter, auktorisationsservrar och skyddade resurser.

2. Gemensamma krav

OpenID Federation definierar ett antal metadatafält som kan användas för samtliga protokollentiteter, bland annat organization_name, display_name, description, contacts, policy_uri, information_uri och organization_uri.

Föreslagen miniminivå:

MetadataKravKommentar
organization_identifierREQUIREDIdentifierar den organisation som ansvarar för protokollentiteten. Ska följa OpenID Federation Organization Identifier Metadata Parameter.
organization_nameREQUIREDLäsbart namn på ansvarig organisation.
display_nameREQUIREDLäsbart namn som identifierar den tekniska komponenten/protokollentiteten.
contactsRECOMMENDEDKontaktuppgift för teknisk eller administrativ hantering av entiteten.
descriptionOPTIONALKort beskrivning av entiteten.
information_uriOPTIONALLänk till ytterligare information om entiteten.
organization_uriOPTIONALLänk till ansvarig organisation.


Organisationsidentifieraren bör vara central eftersom federationsplattformens tekniska ramverk redan anger att denna metadata används för att koppla en teknisk komponent till ansvarig organisation.

3. Protokollnycklar

Om en protokollentitet använder asymmetriska nycklar i OAuth-protokollet ska dess publika protokollnycklar kunna hämtas från metadata.

Följande mekanismer definieras av OpenID Federation:

Dessa nycklar är separata från de federationsnycklar som används för att signera Entity Statements.

Förslag: en entitet som behöver publicera protokollnycklar ska publicera dessa genom en av de mekanismer som tillåts av den tekniska profilen. Vi bör alltså inte göra jwks specifikt REQUIRED om exempelvis signed_jwks_uri ska vara det föredragna alternativet.

4. OAuth Client

Entity type: oauth_client.

OIDF tillåter metadata enligt OAuth Dynamic Client Registration samt gemensamma OpenID Federation-metadata.

Föreslagna krav:

MetadataKravKommentar
Gemensamma metadata enligt avsnitt 2REQUIRED enligt ovan
grant_typesREQUIREDAnger vilka OAuth grant types klienten använder.
token_endpoint_auth_methodREQUIREDAnger hur klienten autentiserar sig mot AS.
token_endpoint_auth_signing_algCONDITIONALSka anges när vald autentiseringsmetod kräver signering, exempelvis private_key_jwt.
jwks, jwks_uri eller signed_jwks_uriCONDITIONALKrävs när klientens protokollnycklar behöver vara tillgängliga för andra parter.


Scope bör tills vidare inte göras till obligatorisk federationsmetadata. Vilka scopes en viss klient faktiskt är behörig att använda hör normalt till klientregistreringen hos AS och bör hållas isär från beskrivningen av klientens federativa identitet.

5. OAuth Authorization Server

Entity type: oauth_authorization_server.

OIDF anger att metadata enligt RFC 8414 och relevanta registrerade metadatafält får användas. issuer har dessutom ett uttryckligt OIDF-krav: värdet ska motsvara entitetens Federation Entity Identifier.

Föreslagna krav:

MetadataKravKommentar
Gemensamma metadata enligt avsnitt 2REQUIRED enligt ovan
issuerREQUIREDSka motsvara Federation Entity Identifier.
token_endpointREQUIREDEndpoint för utfärdande av access tokens.
grant_types_supportedREQUIREDGrant types som AS stöder.
token_endpoint_auth_methods_supportedREQUIREDTillåtna autentiseringsmetoder för klienter.
token_endpoint_auth_signing_alg_values_supportedCONDITIONALSka anges om signerad klientautentisering används.
scopes_supportedRECOMMENDEDScope som AS kan utfärda.
jwks, jwks_uri eller signed_jwks_uriREQUIRED när publika protokollnycklar behövsExempelvis för verifiering av signerade JWT.


6. OAuth Protected Resource / Resource Server

Entity type: oauth_resource.

OIDF anger att gemensamma metadata kan användas och att en deployment dessutom får använda Protected Resource Metadata enligt RFC 9728.

Föreslagna krav:

MetadataKravKommentar
Gemensamma metadata enligt avsnitt 2REQUIRED enligt ovan
resourceREQUIREDIdentifierar den skyddade resursen.
authorization_serversRECOMMENDEDAnger vilka Authorization Servers som kan användas för resursen.
scopes_supportedRECOMMENDEDAnger vilka OAuth scopes resursen känner till.
bearer_methods_supportedOPTIONALOm relevant för vald interoperabilitetsprofil.
jwks, jwks_uri eller signed_jwks_uriCONDITIONALKrävs endast om Resource Server har protokollnycklar som andra parter behöver verifiera.


Här skulle jag vara mer försiktig än för Client och AS. Exakt vilka RFC 9728-fält som ska vara REQUIRED bör avgöras tillsammans med användningsfallen och Ena OAuth-profilen, eftersom OIDF själv endast anger att dessa metadata får användas.

7. Metadata policy

De krav som lämpar sig för maskinell kontroll bör kunna uttryckas genom OpenID Federations metadata_policy.

OIDF anger uttryckligen att Trust Anchors och Intermediate Entities kan använda metadata policy för att säkerställa interoperabilitet eller följsamhet mot en säkerhetsprofil. Policyn är dessutom knuten till specifik entity type och enskilda metadatafält.

Exempel på krav som sannolikt lämpar sig för sådan kontroll är:

Jag skulle sätta REQUIRED på organization_identifier, organization_name och display_name för alla tre, och därefter hålla de protokollspecifika kraven relativt snäva. Då normerar vi det som faktiskt behövs för identifiering och interoperabilitet utan att göra federationsmetadata till ett klient- eller behörighetsregister