...
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:
oauth_clientoauth_authorization_serveroauth_resource
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å:
...
| Metadata |
|---|
...
| Krav |
|---|
...
| Kommentar |
|---|
...
...
organization_identifier |
...
| REQUIRED |
...
| Identifierar den organisation som ansvarar för protokollentiteten. Ska följa OpenID Federation Organization Identifier Metadata Parameter. |
...
...
organization_name |
...
| REQUIRED |
...
| Läsbart namn på ansvarig organisation. |
...
...
display_name |
...
| REQUIRED |
...
| Läsbart namn som identifierar den tekniska komponenten |
...
| /protokollentiteten. |
...
...
contacts |
...
| RECOMMENDED |
...
| Kontaktuppgift för teknisk eller administrativ hantering av entiteten. |
...
...
description |
...
| OPTIONAL |
...
| Kort beskrivning av entiteten. |
...
...
information_uri |
...
| OPTIONAL |
...
| Länk till ytterligare information om entiteten. |
...
...
organization_uri |
...
| OPTIONAL |
...
| Lä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
...
:
jwksjwks_urisigned_jwks_uri
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:
| Metadata | Krav | Kommentar |
|---|---|---|
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
grant_types |
...
| REQUIRED |
...
| Anger vilka OAuth grant types klienten använder. |
...
...
token_endpoint_auth_method |
...
| REQUIRED |
...
| Anger hur klienten autentiserar sig mot |
...
| AS. |
...
...
token_endpoint_auth_signing_alg |
...
| CONDITIONAL |
...
Ska anges när vald autentiseringsmetod kräver signering, exempelvis private_key_jwt. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| CONDITIONAL |
...
| Krä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:
...
| Metadata |
|---|
...
| Krav |
|---|
...
| Kommentar |
|---|
...
...
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
issuer |
...
| REQUIRED |
...
| Ska motsvara Federation Entity Identifier. |
...
...
token_endpoint |
...
| REQUIRED |
...
| Endpoint för utfärdande av access tokens. |
...
...
grant_types_supported |
...
| REQUIRED |
...
| Grant types som |
...
| AS stöder. |
...
...
token_endpoint_auth_methods_supported |
...
| REQUIRED |
...
| Tillåtna autentiseringsmetoder för klienter. |
...
...
token_endpoint_auth_signing_alg_values_supported |
...
| CONDITIONAL |
...
| Ska anges om signerad klientautentisering används. |
...
...
scopes_supported |
...
| RECOMMENDED |
...
| Scope som |
...
| AS kan utfärda. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| REQUIRED när publika protokollnycklar behövs |
...
| Exempelvis 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:
...
| Metadata |
|---|
...
| Krav |
|---|
...
| Kommentar |
|---|
...
...
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
resource |
...
| REQUIRED |
...
| Identifierar den skyddade resursen. |
...
...
authorization_servers |
...
| RECOMMENDED |
...
| Anger vilka Authorization Servers som kan användas för resursen. |
...
...
scopes_supported |
...
| RECOMMENDED |
...
| Anger vilka OAuth scopes resursen känner till. |
...
...
bearer_methods_supported |
...
| OPTIONAL |
...
| Om relevant för vald interoperabilitetsprofil. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| CONDITIONAL |
...
| Krä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:
- att obligatoriska metadata finns
- tillåtna
grant_types - tillåtna klientautentiseringsmetoder
- tillåtna algoritmer
h2. 8. Avgränsning
Federationsmetadata ska beskriva protokollentiteten och sådant som andra parter behöver kunna upptäcka och verifiera.
...
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