Value issue fixed. vct changed to type

[andreasabr]

There was an issue with the issuer metadata. In the RFC001 we used two time the key name"vct" for the verifiable credential type which does not exist in the OIDC4CI standard. The correct key name is "type". I changed it.

[ntsbs]

I think this was based on the credential definition for SD-JWT VC in HAIP:
https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-7.2.2-3

OID4VCI draft 12 has no profile defined for SD-JWT VC

OID4VCI draft 13 (ID.1) defines vct on a higher level

I would keep the current version of HAIP and adopt the changes of draft 13 with the move to ID.1

[andreasabr]

That is correct @ntsbs. Nevertheless, RFC001 refers to draft 12, and this draft does not mention "vct". For the first piloting, we decided to not use SD-JWT and focus on our RFC001, therefore, it makes more sense to update the RFC001 after the first piloting. @lalc @georgepadayatti @endimion please add your comments

[lalc]

That is correct @ntsbs. Nevertheless, RFC001 refers to draft 12, and this draft does not mention "vct". For the first piloting, we decided to not use SD-JWT and focus on our RFC001, therefore, it makes more sense to update the RFC001 after the first piloting. @lalc @georgepadayatti @endimion please add your comments

Yes I agree.

[ntsbs]

For the first piloting, we decided to not use SD-JWT and focus on our RFC001

If you are not using SD-JWT then why would you change the SD-JWT example? The example that you changed is the profile definition for SD-JWT

[endimion]

On the ITB and issuer I will update the definition as "type" instead of vct for non sd-jwt cases. In sd-jwt cases this will remain as vct.

[andreasabr]

If the RFC refers to draft 12 (as previously agreed on), we have to change the value to "type", otherwise it breaks the interoperability and does not comply anymore with the standard. Otherwise, we have to refer to a newer version of the draft e.g. v13. This adoption is considered anyway, but not directly before the piloting is happening.

[lalc]

If the RFC refers to draft 12 (as previously agreed on), we have to change the value to "type", otherwise it breaks the interoperability and does not comply anymore with the standard. Otherwise, we have to refer to a newer version of the draft e.g. v13. This adoption is considered anyway, but not directly before the piloting is happening.

Should we move to version 13, make an interim EWC RFC version 1.1 release, and not wait for June? The impacts seem relatively straightforward. The justification is also that draft 13 is the approved version now. Please vote up/down so we can decide.

[lalc]

I will merge to main for now, and let's aim to move to draft-13 on 01-June. Please use issue #47 to decide on the precise switching date.