search

solid / authentication-panel

GitHub repository for the Solid Authentication Panel
MIT License
11 stars 15 forks source link

Use verifiable Identity Credential instead of Access Token #94

Closed elf-pavlik closed 3 years ago

elf-pavlik commented 3 years ago

closes #60

This is early version just so that we can have a reference for Monday's call. As you may see at this moment it only uses DPoP with IdP to bind Identity Credential to client's public key. When making request to RS i just uses JWS of the Verifiable Presentation.

I still need to write down example where more than one credentials are being presented by the client. Otherwise it may be hard to justify proposed changes. As additional issue I would like to discuss exchanging Verifiable Presentation for simple Access Token in similar way as proposed in https://github.com/zenomt/webid-auth-protocol#token_pop_endpoint-api-parameters

acoburn commented 3 years ago

Is the intent here to make DPoP and VC two possible mechanisms for authentication (with the idea that there could be more in the future)? Or is the intent to remove DPoP and replace it with VC (and have only a single mechanism for authentication)?

elf-pavlik commented 3 years ago

As the draft currently stands it doesn't seem to address any authorization related requirements, including user constraining client's access (while not acting as resource controller), or client presenting specific verifiable credential (eg. membership) to gain access to a resource. At the same time current draft makes exclusive use of HTTP Authorization header by mandating it to include Access Token signed by IdP. In current state of this PR it still relies on DPoP for binding VC to client's public key.

dmitrizagidulin commented 3 years ago

Although I think that VCs make a better cross-domain identifier thant he global Access Token (which is why I had them in the previous draft), I suspect this proposal would be better in addition to, as opposed to instead of, the current access token structure.

elf-pavlik commented 3 years ago

Specifically, what I would be interested in seeing is a proposal that either layers VC on top of the current DPoP access token structure

I think with current draft, they only way to 'layer something on top', would require IdP to take responsibility of including more data in the access token. Since it is signed by IdP and RS needs to verify that signature, only IdP can include some additional claims (eg. VCs) in the Access Token. I think we need to decide if we want to have IdP with very limited responsibility and have other services taking other responsibilities, or IdP would be expected to handle various other responsibilities than OP.

elf-pavlik commented 3 years ago

@acoburn: I think that this might be better structured as a proposal in addition to or along side of the current recommendation.

@dmitrizagidulin: I suspect this proposal would be better in addition to, as opposed to instead of, the current access token structure.

Could you explain how do you see it used in addition? Especially if we would want to give additional responsibilities to party different than IdP, neither that extra party or the client can alter the Access Token in any way.

acoburn commented 3 years ago

@elf-pavlik there are several possibilities (these are all just off the top of my head)

  1. A secondary identity service could be used to exchange DPoP-bound access tokens for VC tokens.

Here, an agent would authenticate with an identity provider as per the current spec. The resulting access token can be given to a VC-capable service and exchanged for a new token. That new token would be given to the resource server. This approach is more of a layering on top of the existing spec flows.

  1. A VC-capable identity provider would exist in place of the current OIDC-based flows.

Here, there would be no OIDC access token (from the current spec); only the VC token would be given to a client app.

In both cases, resource servers would use different mechanisms for validating these incoming tokens: webid claims + DPoP confirmation for the Solid-WebId approach; VC identifiers for this new approach. It will be crucial for resource servers to be able to (a) distinguish between these different token types and (b) advertise support for these different mechanisms.

elf-pavlik commented 3 years ago

I think IdP might need to be responsible for provide any needed credential to the client and changes in this PR don't go in that direction. Just as user would want to set restrictions on what client can access (we can think OAuth scopes), user would also want to have control over which credentials client can get to use when accessing resources.