DIIP V4 Specifications

[k00ij]

Below the suggestion for the DIIP V4 specs as a starting point for further discussion.
Wallets are now split up in different categories. This means that a wallet can for instance be conformant with the DIIP V4 “Organizational Wallets – Issuer” specs but not with the “Organizational Wallets – Holder” specs.

One of the topics for discussion is if DIIP V4 needs to specify which parts of the various specs need to be supported or that we assume that all parts of the various specs need to be implemented in the wallets.

Please add your feedback as a comment in this thread. Anyone can participate in the discussion.

DIIP V4
				Organizational Wallet
		Personal Wallet		Issuer	Holder	Verifier
Issuance	OID4VCI ID2 draft 15	x		x	x
Presentation	OID4VP ID3/draft 23	x			x	x
Credential Formats	IETF SD-JWT VC draft 8	x		x	x	x
	ISO mDOC 18013-5	x		x	x	x
	VCDM 2.0/SD-JWT (vc+sd-jwt)	x		x	x	x
Protocol for User Authentication by the Wallet at a Verifier	SIOP V2	x			x	x
Identifiers - Organizations	web-based key resolution/jwks	x		x	x	x
	x.509 based key resolution (x509_san_dns&uri)	x		x	x	x
	DID:Web	x		x	x	x
	DID:Webvh (whois)	x		x	x	x
Identifiers - Persons	JWK	x		x		x
	DID:JWK	x		x		x
Signature types	ES256	x		x	x	x
	ECDSA – P256	x		x	x	x
Encryption	ECDH-ES	x		x	x	x
Status list & Revocation	IETF Token Status List Draft 6 of 8	x		x	x	x

 

 

 

[k00ij]

In addition to the listed specs there is a suggestion for wallets in the category "Organizational Wallet - Verifier" to agree on using an "OID4VP API spec". This would allow an even quicker setup of verifier/relying party solutions (web mobile or native app) with flexible choice of integrating any compliant org wallet. The initial architecture has been setup and implemented by Sphereon and Credenco but we may include it in the DIIP V4 specs if there are sufficient other org wallet developers that see the benefit and want to implement it.

Credenco - OpenID4VP API.pdf

[samuelmr]

Rename "Identifiers - Organizations" to "Identifiers - verifiers and issuers".

[samuelmr]

Add two options for trust establishment:
a) "Verifier knows issuer and holder knows verifier"
b) OpenID Federation

[samuelmr]

Drop the requirement to support 18013-5.

[samuelmr]

Reasoning: keep things simple. Let HAIP be the mDoc profile.

[samuelmr]

Instead of "Organizational Wallet / Issuer" and "Organizational Wallet / Verifier" use terms "Issuer Agent" and "Verifier Agent".

[samuelmr]

Reserve the term "Wallet" to mean holding and presenting credentials.

[samuelmr]

What about the support for Digital Credentials API? Not ready for real use yet?
https://digitalcredentials.dev/docs/ecosystem-support

[samuelmr]

Drop DID:JWK unless someone presents real benefits it brings over plain JWK.

[samuelmr]

Add explanatory text specifying that the DIIP profile doesn't require the credentials to be bound to the holder's keys (device binding). JWK should be used to identify the holder (subject) only in cases where cryptographic device binding is required. Otherwise, the issuers are free to use an email, a social security number, or any other identifier that suits the needs of the use case.

[samuelmr]

What is the actual spec to do web-based key resolution/jwks? Issuer is identified by "https://example.com/myRandomJWKS.json"?

[samuelmr]

OID4VCI issuance flow variations leaves room for optionality.

Suggestion:

• Authorization Code Flow or Pre-Authorized Code Flow: DIIP should require support for both
• Wallet initiated or Issuer initiated: DIIP should probably require support for both
• Same-device or Cross-device Credential Offer: DIIP should require support for both
• Immediate or Deferred:: DIIP should only require support for immediate

[samuelmr]

OID4VP optionality: Authorization Request parameters: presentation_definition, presentation_definition_uri, or dcql.

Suggestion: support for dcql is mandatory for DIIP v4 conformance.

[samuelmr]

OID4VP optionality: client id schemes: redirect_uri, https, did, verifier_attestation, x509_san_dns, x509_san_uri, web-origin

Suggestion:

• If we want to keep DID support in DIIP, did must be supported by DIIP v4 conformant implementations.
• If we prefer the old-school X.509 certificates as issuer and verifier identifiers, I think it might make sense to mandate support for x509_san_dns and/or x509_san_uri
• I think redirect_uri is quite well supported, should we require it to be supported?
• I like OpenID Federation, so I would like to include https
• we might encourage adding support for web-origin and anticipate it to be a requirement in DIIP v5

[samuelmr]

See some discussion about the client id schemes: openid/OpenID4VP#401

[nanderstabel]

So the overview above still contains SIOPv2, but apparently it has been removed from the spec here. I missed a couple of DIIP meetings, so could someone explain why it is now completely omitted?