search

Sphereon-Opensource / OID4VC-demo

Demo for OID4VC, containing a configurable agent, OID4VCI Issuer and demopage as well as SIOPv2 and OID4VP RPs with demo page
Apache License 2.0
17 stars 8 forks source link

Question about some SIOPv2 specification details #8

Open nanderstabel opened 1 year ago

nanderstabel commented 1 year ago

I was playing around with the example and I noticed two things regarding how some of the SIOPv2 specifications are implemented.

Firstly, I noticed that when Authorization Response is returned to the endpoint specified in the redirect_uri, it will be rejected when its iss value is not set to "https://self-isued.me/v2", e.g.:

verifyAuthenticationResponseJwt failed: Error: The Response Token Issuer Claim (iss) MUST start with https://self-isued.me/v2, got: did:key:z6MkfeU6K1HNu5G8saotMzUmiAPoche1k942rTqWkgEfxh3S

As far as I understand this is compliant with section 7.4 in the OpenID Connect core specification: "1. The iss (issuer) Claim Value is https://self-issued.me.". However, in section 11 of the SIOPv2 specification, the iss claim is described as: "REQUIRED. in case of a Self-Issued ID Token, this claim MUST be set to the value of the sub claim in the same ID Token.", where the sub claim can be either a JWK Thumbprint, or a Decentralized Identifier.

On validation of the ID Token in section 11 of SIOPv2 it is mentioned that "1. The Relying Party (RP) MUST determine whether the ID Token has been issued by the Self-Issued OP. The ID Token is self-issued if the issclaims and the subclaim have the same value. If both values differ, the ID Token MUST be processed as defined in [OpenID.Core], section 3.2.2.11.."

In section 3.2.2.11 there is no mention anymore of "https://self-isued.me/v2". So I was wondering what your thoughts are about this? My interpretation of all of this is that using "https://self-isued.me/v2" has become obsolete with the introduction of using DIDs or JWK Thumbprints in SIOPv2.

The second thing I noticed is that the client_id is not present in the Authorization Request used in this example:

"openid-vc://?request_uri=http%3A%2F%2Flocalhost%3A3002%2Fext%2Fdefinitions%2F9449e2db-791f-407c-b086-c21cc677d2e0%2Fauth-requests%2F629773a7-ce3d-4d30-8363-79b5453163fe"

Only the request_uri parameter is present. However, according to SIOPv2, the client_id MUST be present when either the request or the request_uri parameter is present: https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#section-9-7

I guess that's just a minor detail and perhaps not very important for this example repo. I'm just pointing this out to check whether I am missing something in my understanding :smile:

nklomp commented 1 year ago

Hi @nanderstabel

Thanks for you detailed report. I will come back to you after easter with a more elaborate answer.

But to already provide you with some feedback. Our underlying SIOPv2/OID4VP library has version discovery. So it supports multiple versions of the SIOPv2/OpenID4VP specs. Depending on the version discovered, or the version supplied it will behave differently, as the different versions have moved/changed things considerable overtime. Having said that, we currently do not have full support for V12 of OpenID4VP yet. The focus has mostly been on the DID-JWT VC Presentation Profile, which uses Implementers Draft 1 (ID1), as that is the one we use for interop testing with other parties and is being used in the wild the most. We will update the latest versions as well, as soon the next Implementers Draft will come out. Our policy is to support versions that are used in the wild, implementers drafts, as well as to update a certain intervals to the latest version available, to ensure we do not spent endless resources on interim versions which will never be used. As a result we are not always up to date with exactly the latest spec.

The fact you are only seeing the request_uri is a direct result of the JWT VC Presentation profile. The lower level library supports where properties endup. They can endup in the URI in OAuth2 style or in the Request Object in OpenID style, or in both. The builder has a target per property that you can optionally use to define where any property should end up. You can also see that we use ID1 and also the concept of targets in the builder at: https://github.com/Sphereon-Opensource/SIOPv2-OpenID4VP-example/blob/98d01a8e2bd1694ec70f036668fb93dc8b18a177/packages/siopv2-openid4vp-example-backend/src/Verifier.ts#L39

Lastly and not directly related to your ticket, but probably good to know is that basically all of the backend code is currently being integrated into our SSI-SDK as separate modules you can enable on the agent, including persistence of presentation definitions. So the example repo will for sure be updated next few weeks, making the example simpler to use.

Happy easter!

nanderstabel commented 1 year ago

Thank you very much for explaining! There are a lot of nuances in the different specifications related to SIOP and OD4VP and your description helps a lot to understand them better. I haven't checked out the different Presentation Profiles yet so I will definitely do that. I will also check out your SSI-SDK :)

nanderstabel commented 1 year ago

Reopened the issue since you mentioned you might want to come with a more elaborate answer which would be greatly appreciated :)