OID4VCI: Align RFC001 with latest approved version 13

EWC-consortium / eudi-wallet-rfcs

EU Digital Identity Wallet RFCs in EWC to align towards the Large Scale Pilot (LSP) usecases. The project is co-funded by the European Union.

https://eudiwalletconsortium.org/

Apache License 2.0

21 stars 13 forks source link

OID4VCI: Align RFC001 with latest approved version 13 #47

Closed lalc closed 1 week ago

lalc commented 5 months ago

OpenID for Verifiable Credential Issuance Draft 13 is approved.

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

[x] Check all fields in all messages
[x] Draft 13 seems like using credential_configuration_ids over credentials in EWC RFC001

ntsbs commented 5 months ago

Are we planning to switch on a specific date?

lalc commented 5 months ago

Are we planning to switch on a specific date?

We can decide this jointly. My idea was to get it up in June as this doesn't seem so urgent. Do share your thoughts.

We need to agree also on a process how we introduce the changes. For now, the first release v1.0 holds and our target for next release (2.0) is June. I am planning to have a bi-weekly follow up for new RFCs that we need to introduce, mainly PID / LPID issuance, wallet attestation and payment scenarios.

ntsbs commented 5 months ago

June sounds good

andreasabr commented 5 months ago

@lalc I think regular meetings in which we are discussing the RFC sounds like a good idea.

For the release of a new version of the RFC I would suggest to consider a date that does not interfere with the piloting and pilot preparation processes.

mat-work commented 4 months ago

+1 for June

lalc commented 4 months ago

Based on this conversation, we will make a new release on 01-June. Please confirm. @endimion @georgepadayatti @ntsbs @mat-work @andreasabr

andreasabr commented 4 months ago

Hi everybody,

I think its good to move forward. Nevertheless, I think if we decide to move to draft v13, we have to spend time reviewing the changes made in the new version and also if our RFC complies with this version. This will take some effort, and I doubt that it can be completed on time (at least from our side).

On the other hand, we agreed a long time ago that we should not do RFC updates right before the piloting, in order to give the partners time to work with a stable version and to focus on the piloting.

Finally, the benefits of moving to v13 is not clear why that is considered before the piloting since we agreed months ago that SD will not be part of the piloting. The suggestion from the old conversations was to make simple things right instead of overcomplicating things. Piloting should be an incremental process, starting with a simple and minimal setup now and advancing its complexity for the final large-scale piloting.

lalc commented 4 months ago

I think its good to move forward. Nevertheless, I think if we decide to move to draft v13, we have to spend time reviewing the changes made in the new version and also if our RFC complies with this version. This will take some effort, and I doubt that it can be completed on time (at least from our side).

Please suggest a suitable time before the end of June to agree on moving to draft 13. Draft 13 is the approved spec, and we don't want to be lagging behind.

@endimion @georgepadayatti @ntsbs @mat-work @andreasabr

mat-work commented 4 months ago

Hi @lalc, at SICPA, we are aiming to release Draft 13 between the first and second weeks of June.

ntsbs commented 3 months ago

Mid of June (14th June) should be fine for us

andreasabr commented 3 months ago

Since we are currently focusing on the piloting, we would only start working on reviewing and adopting the RFC in a bit. Therefore, I would aim at the beginning of July to be able to release the updated RFC.

Keep in mind, this discussion is about when to release the updated version of the RFC and not when an implementation is ready.

lalc commented 3 months ago

Here is what I propose based on this discussion:

Schedule the release of version 2 of the EWC RFCs, adopting draft 13 of OID4VCI, for 28 June 2024.
Compliance with ITB standards is the responsibility of wallet providers. The release of the EWC RFCs should proceed independently of the wallet providers' compliance plans.

andreasabr commented 3 months ago

Thank you @lalc. I agree, and we can proceed with your suggestion.

pa-rw commented 2 weeks ago

Hi, the link for reference [1] in RFC001 is pointing to draft-14 of openid4vci. Could you please update it to point to https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html instead?

georgepadayatti commented 2 weeks ago

Hi, the link for reference [1] in RFC001 is pointing to draft-14 of openid4vci. Could you please update it to point to https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html instead?

Noted. Will fix the same in the PR. Will use the implementor draft 1 (ID1) URL which in turn points to draft 13. https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html

lalc commented 2 weeks ago

Hi, the link for reference [1] in RFC001 is pointing to draft-14 of openid4vci. Could you please update it to point to https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html instead?

Annoying when standards orgs do not follow basic naming rules. 😉

The approach OpenIDF takes is that the current WG draft is always published without a version identifier in the URL. 😊

pa-rw commented 2 weeks ago

I think that in the issuer metadata example (chapter 3.4 Discover response) _cryptographic_suitessupported should be _credential_signing_alg_valuessupported.

lalc commented 1 week ago

I think that in the issuer metadata example (chapter 3.4 Discover response) _cryptographic_suitessupported should be _credential_signing_alg_valuessupported.

This is now fixed as part of PR #63

lalc commented 1 week ago

Closing this issue as part of PR #63 merge