search

swedenconnect / technical-framework

Technical Specifications for the Swedish eID Framework
27 stars 3 forks source link

OAuth 2 Specifications for Sweden Connect #191

Open martin-lindstrom opened 1 year ago

martin-lindstrom commented 1 year ago

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:

Suggestion

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

Resources

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

Interesting links

AndersTornqvist commented 1 year ago

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*:

[*]: 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:

Suggestion

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

Resources

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

Interesting links

— Reply to this email directly, view it on GitHub https://github.com/swedenconnect/technical-framework/issues/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 commented 1 year ago

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 commented 1 year ago

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).