Closed OIDF-automation closed 2 months ago
Before getting into the protocol mechanics, a fundamental question I have is… For both mdocs and SD-JWTs, how does changing only the DeviceKey to which a credential is bound, without changing the randoms/salts for each data element/claim helps “prevent relying party collusion”? For both mdocs and sd-jwts, issuer sign over the digest that is a hash over both random value and the actual claim value. If this random value stays the same, that results in the same hashes in the MSOs/JWS and becomes a correlation factor. If this random value needs to be communicated, I don’t see much value in duplicating only the issuer-signed parts because for each issuer-signed parts, the combination of random values to the plain text claim value also needs to be communicated, in which case, issuing multiple entire credentials sounds simpler… (though I understand portrait images are huge.)
jfyi tThis is the input for the Digest in MSO
IssuerSignedItem = {
"digestID" : uint, ; Digest ID for issuer data authentication
"random" : bstr, ; Random value for issuer data authentication
"elementIdentifier" : DataElementIdentifier, ; Data element identifier
"elementValue" : DataElementValue ; Data element value
}
cc @{5b73d0fb816d1805baacb64f} @{557058:158fed82-ec3f-409f-ac62-6035c3a106df}
Thank you for your comment Kristina.
how does changing only the DeviceKey to which a credential is bound, without changing the randoms/salts for each data element/claim helps “prevent relying party collusion”?
the combination of random values to the plain text claim value also needs to be communicated
A couple of small corrections here:
Using mdoc as an example, to send a “full” credential the issuer would need to send:
Mapping of element identifier to:
To send a “dehydrated” credential the issuer would need to send:
Mapping of element identifier to:
The only difference between the two is that the “full” credential response would contain the element values. The digest IDs and salt would be different for each credential.
issuing multiple entire credentials sounds simpler
It may be simpler but it doesn’t address the issue.
I would appreciate if you could also comment on the secondary issue - how should the issuer communicate to the wallet the number of credential copies that it should request? Is my suggestion of including it in credential format specific Issuer Metadata a good idea?
SIOP Aug-10-2023 call
Mark Haine mentioned work in ekyc-ida that might be relevant openid / ekyc-ida / Pull Request #169: Move attachments to a separate document — Bitbucket
we discussed that the options chose will not have impact on how the response is encrypted because the entire response will one or more credentials issued is entirely encrypted as JWE.
we discussed that the same mechanism should apply to both credential and batch credential endpoints.
Kristina expressed the preference to define a new credential format that signals issuance of “dehydrated” credential because the wallet needs to know what it is receiving and that is not straightforward when only proof
is modified like in two other proposals.
@Jacob, follow up question on the actions required for the holder and the verifier for “dehydrated” credential.
when the holder receives the credential, it will have to receive one full credential and multiple dehydrated credentials. assuming that the fact that the issuer signs over the claim value too, when the wallet sends a credential to the to verifier, the wallet will have to reproduce digest id, salt, element value
combination based on full credential and dehydrated credentials, correct? that’s a lot…
I have been thinking about this a litte, and I think the simplest way to do this with mdoc and sd-jwt is to define a string (“dehydrated” for example) that goes instead of a plaintext claim value in a dehydrated credential. this might or might not have an impact on the protocol side. on one hand, it would be easier to negotiate between wallet and the issuer if there is a new format identifier for dehydrated, but on the other hand, it is pretty much still the same credential format from a structural perspective, so if the issuer knows the wallet supports dehydrated credentials, it actually might just issue dehydrated ones in response to the same 1mso_mdoc credential format requests.
We do have a discussion on this in SD-JWT, see https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/329
My impression is that such a ‘dehydrated’ credential or similar techniques are just highly specialized compression algorithms. So why not use GZIP?
GZIP’ing HTTP requests is already a default today.
At least for SD-JWT, bunches of similar credentials will be highly compressable. At most there should be three copies of any large data field (when the bytes are not aligned in the base64 representations), but with simple optimizations (using the same order of fields and same byte lengths for keys and nonces), the issuer can bring that down to exactly one copy. Bonus feature: All your other data fields will be compressed as well.
GZIP can be applied not only for transfer, but also for storage.
Compared to any of the proposed solutions above, at least the transport part should be extremely easy to implement. The storage part may be a bit more complex, but it’s not rocket science either.
(Replace GZIP above by your favorite algorithm.)
Thanks Daniel, that’s a good point. It doesn’t cover all cases however, such as when the issuer is just issuing a new credential(s) without any updates to the claims – in that case it would want to only send dehydrated credentials.
Issue #1930 was marked as a duplicate of this issue.
Is there an example in the wild using "dehydrated credentials". I'm asking since I feel this discussion tries to come up with a reasonable solution for "compression" and at the same time with a protocol able to issue such credentials. I believe we should stick to defining protocols for existing credential formats.
Given there's a decision not to address this in SD-JWT ( https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/329 ) I don't see that there's anything we can do in the VCI spec so I think we can close this ticket?
Hence marking as pending close. Please comment if I missed something.
Closing as per previous comment as there's been no objections. Feel free to comment if you see a way forward and we can reopen.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2003
Original Reporter: cobward
Situation:
To prevent relying party collusion and thereby improve user privacy, an issuing authority wants to provide multiple one-time use copies of a credential to a wallet, each bound to a different keypair in the wallet. Unfortunately some of the claims in the credential are very large, for example a user portrait image, so simply using the batch credential endpoint would result in a needlessly large response size due to duplicated claims. The credential format is an “sd-cred”, similar to an sd-jwt or mdoc, where the unblinded claims could be transmitted separate from the signed credential.
A secondary issue, is that the issuing authority needs a mechanism through which to inform the wallet of how many copies of the credential it should request.
Possible solutions:
I have though of three possible solutions to the main issue:
Requiring no changes to the specification, a new credential format identifier “sd-cred” could add an additional “non-core” parameters to the credential request structure, for example:
The following additional parameter is defined for Credential Requests and this Credential format.
extra-proofs
: OPTIONAL. A JSON array of additionproof
objects of wallet-bound public keys to which should be issued “claimless” credentials.
Requiring no changes to the specification, a new proof type “jwts-claimless” could be defined for use with the “sd-cred” credential format identifier:
The following proof type is defined for use in Credential Requests and this Credential format.
jwts-claimless
: objects of this type contain a singlejwts
element which is a JSON array of JWTs as defined in Section 7.2.1 of OID4CI.
In the last two cases the batch of credentials should all be encoded in a single
credential
field, as defined for this credential format identifier.I believe the secondary issue can be easily resolved through defining a new field in the issuer metadata for that credential format.
Please let me know which of any of these solutions are suitable for use with OID4CI, or if there are better ways forwards.