OAuth 2 Specifications for Sweden Connect

[martin-lindstrom]

Currently, Sweden Connect provides specifications regulating authentication and federated signing. The roadmap also includes extending the authentication specifications with profiles for OpenID Connect. Authorization and delegated rights have so far been out of scope for the Sweden Connect specifications.

The lack of a national profile for how to handle authorization and delegation has led to a number of solutions where proxy SAML-IdP:s are used to issue assertions containing both identity attributes and role information. Also, SAML-assertions are passed around between services as "proof" of a logged in user. And perhaps the worst thing, user data is shared among services with no involvement or knowledge of the user (that owns the data). These homemade attempts to solve some of the issues that arise concerning authorization and delegation falls under "driving in a nail using a screwdriver", i.e., using the wrong tool to solve the problem.

So, which areas do we need to address in a standardized fashion?

For a Resource Server^*:

• Centralized support for authentication and authorization of calling entities, i.e., how shall a resource server authenticate and authorize calls to it?
• Before delivering the user's data in a response message the Resource Server needs proof of the user's consent to do so.
• Extending the previous item: The Resource Server requires proof of that the calling entity has the user "logged in" before delivering user owned data to the calling entity.

[*]: We define a Resource server to be an entity (service) that in some way service's a user's data, for example an API-server that delivers data owned/belonging to a user or a web site that presents the user's data.

Other areas:

• We need standardized ways to handle user-to-user delegation (and/or impersonation). For example, user A gives user B rights to represent him or her (for a given service).

• Easier setup of services is required. A centralized "metadata" service holding the registration data for authorization servers, clients and possibly also resource servers will be needed. This repository will hold keys, adresses and relevant registration metadata.

Suggestion

The Sweden Connect technical specifications are extended with support for authorization and delegation, with profiles/specs covering:

• An OAuth 2 interoperability profile.

• Attribute (claims) definitions.

• Representations of "ID tokens" as part of an JWT access token.

• Specifications for client authentication.

• Registration requirements (metadata).

Resources

This section lists documents that we should look into and extend/specialize during the work:

• RFC6749 - The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6749.

  • International Government Assurance Profile (iGov) for OAuth 2.0 - Draft 03 - https://openid.net/specs/openid-igov-oauth2-1_0.html.

• OAuth 2.1 draft - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07.

  • https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1

• RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens - https://www.rfc-editor.org/rfc/rfc9068.html.

  • RFC7519 - JSON Web Token (JWT) - https://www.rfc-editor.org/info/rfc7519.

  • RFC8725 - JSON Web Token Best Current Practices - https://www.rfc-editor.org/info/rfc8725.

• RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - https://www.rfc-editor.org/rfc/rfc7523.

• RFC 8693 - OAuth 2.0 Token Exchange - https://www.rfc-editor.org/rfc/rfc8693.html.

• RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens - https://www.rfc-editor.org/rfc/rfc8705.

• RFC8707 - Resource Indicators for OAuth 2.0 - https://www.rfc-editor.org/info/rfc8707.

• RFC7643 - System for Cross-domain Identity Management: Core Schema- https://www.rfc-editor.org/info/rfc7643. Section 4.1.2.

• RFC7644 - System for Cross-domain Identity Management: Protocol - https://www.rfc-editor.org/info/rfc7644.

Interesting links

• https://connect2id.com/products/server/docs/guides/oauth-client-authentication

• https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow

• https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow

• https://oauth.net/articles/authentication/

[AndersTornqvist]

Will user-to-user delegation not be solved by attested attributes in the coming EUDI Wallet? Wouldn’t it be a better approach to first define requirements and then the design before going in to specific technologies? Hälsningar/Regards/Grüße Anders Törnqvist +46 (0)768 15 98 10 <https://www.comfact.se/sv-se/Kontakt/Integritetspolicy> Privacy Policy From: Martin Lindström ***@***.***> Sent: Monday, 5 December 2022 12:28 To: swedenconnect/technical-framework ***@***.***> Cc: Subscribed ***@***.***> Subject: [swedenconnect/technical-framework] OAuth 2 Specifications for Sweden Connect (Issue #191) Currently, Sweden Connect provides specifications regulating authentication and federated signing. The roadmap also includes extending the authentication specifications with profiles for OpenID Connect. Authorization and delegated rights have so far been out of scope for the Sweden Connect specifications. The lack of a national profile for how to handle authorization and delegation has led to a number of solutions where proxy SAML-IdP:s are used to issue assertions containing both identity attributes and role information. Also, SAML-assertions are passed around between services as "proof" of a logged in user. And perhaps the worst thing, user data is shared among services with no involvement or knowledge of the user (that owns the data). These homemade attempts to solve some of the issues that arise concerning authorization and delegation falls under "driving in a nail using a screwdriver", i.e., using the wrong tool to solve the problem. So, which areas do we need to address in a standardized fashion? For a Resource Server*: * Centralized support for authentication and authorization of calling entities, i.e., how shall a resource server authenticate and authorize calls to it? * Before delivering the user's data in a response message the Resource Server needs proof of the user's consent to do so. * Extending the previous item: The Resource Server requires proof of that the calling entity has the user "logged in" before delivering user owned data to the calling entity. [*]: We define a Resource server to be an entity (service) that in some way service's a user's data, for example an API-server that delivers data owned/belonging to a user or a web site that presents the user's data. Other areas: * We need standardized ways to handle user-to-user delegation (and/or impersonation). For example, user A gives user B rights to represent him or her (for a given service). * Easier setup of services is required. A centralized "metadata" service holding the registration data for authorization servers, clients and possibly also resource servers will be needed. This repository will hold keys, adresses and relevant registration metadata. Suggestion The Sweden Connect technical specifications are extended with support for authorization and delegation, with profiles/specs covering: * An OAuth 2 interoperability profile. * Attribute (claims) definitions. * Representations of "ID tokens" as part of an JWT access token. * Specifications for client authentication. * Registration requirements (metadata). Resources This section lists documents that we should look into and extend/specialize during the work: * RFC6749 - The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6749. * International Government Assurance Profile (iGov) for OAuth 2.0 - Draft 03 - https://openid.net/specs/openid-igov-oauth2-1_0.html. * OAuth 2.1 draft - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07. * https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1 * RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens - https://www.rfc-editor.org/rfc/rfc9068.html. * RFC7519 - JSON Web Token (JWT) - https://www.rfc-editor.org/info/rfc7519. * RFC8725 - JSON Web Token Best Current Practices - https://www.rfc-editor.org/info/rfc8725. * RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - https://www.rfc-editor.org/rfc/rfc7523. * RFC 8693 - OAuth 2.0 Token Exchange - https://www.rfc-editor.org/rfc/rfc8693.html. * RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens - https://www.rfc-editor.org/rfc/rfc8705. * RFC8707 - Resource Indicators for OAuth 2.0 - https://www.rfc-editor.org/info/rfc8707. * RFC7643 - System for Cross-domain Identity Management: Core Schema- https://www.rfc-editor.org/info/rfc7643. Section 4.1.2. * RFC7644 - System for Cross-domain Identity Management: Protocol - https://www.rfc-editor.org/info/rfc7644. Interesting links * https://connect2id.com/products/server/docs/guides/oauth-client-authentication * https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow * https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow * https://oauth.net/articles/authentication/ — Reply to this email directly, view it on GitHub <#191> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF2UHSEQXBGGIW7OUACERLLWLXGTJANCNFSM6AAAAAASUE672M> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/AF2UHSE6Y6T2VD3W7KLXZHDWLXGTJA5CNFSM6AAAAAASUE672OWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFP7YYOI.gif> Message ID: ***@***.*** ***@***.***> >

[martin-lindstrom]

Will user-to-user delegation not be solved by attested attributes in the coming EUDI Wallet?

Yes. But the wallet will not be used in all cases. But of course, we will closely follow the wallet-work.

Wouldn’t it be a better approach to first define requirements and then the design before going in to specific technologies?

Of course we have discussed and analyzed the requirements although not documented in the scope of the technical framework.

[sven-erik-ceedigh-digg]

Regarding user-to-user delegation, we need to consider the existing national building block for powers and mandates that is already in production for legal persons and currently in development for natural persons:

https://minaombud.se/

This building block is also regarded as the basis for future cross-border evidence exchange using authorization and representation/delegation in the context of the Single Digital Gateway regulation (SDGR).