How to signal user choices during issuing

[David W Chadwick]

This issues concerns the following scenario. The wallet connects to the issuer (either pre-authorised or via the full authorisation route) and the issuer sends to the wallet the set of attributes that it proposes to put into the credential. The user reviews this set and determines that he/she does not want one or more of the attributes to be in the credential. (These obviously have to be optional attributes and not mandatory ones as the user will have no choice over the latter.) The wallet needs to send back the user’s choices to the issuer prior to the issuer issuing the credential. Currently the issuing protocol does not support this flow, so the question is, how best can this be achieved?

[Tobias Looker]

With the full authorization route, this can be accommodated by the client/wallet making use of the authorization_details request parameter to detail which claims they would like authorization to be able to obtain within the resulting credential, so the user consent would be sought prior to this request. For the pre-authorized route, user consent could be sought out of band in how the the pre-authorized code is generated. If we are to consider supporting a preview style function I would strongly suggest it be a seperate endpoint so it doesn’t complicate implementations that dont use this function.

[David W Chadwick]

A new endpoint ( called Preview as a working title) is suggested for this. See PR 222.

[David W Chadwick]

Having reviewed this again, a much cleaner solution is for the wallet to include the unsigned credential that it wants to be issued in the request to the credential endpoint. The issuer can then check that this is a subset of the credential that it is prepared to issue, and if it is, go ahead and issue the credential.

[Torsten Lodderstedt]

From a technical standpoint, this issue is about the ability to signal to the issuer what claims to put in a credential.

As far as I understand (from our private conversation), this ability is needed in your implementation since you issue VCs on-demand for particular RPs. This means there is already a grant set up for the wallet to obtain credentials (as pre-authorized by the user) and your wallet would turns around to the issuer in any presentation request and asks the issuer to mint a new VC with the claims as requested by the respective RP.

For specifying the credential content, I suggest to utilize the same approach we already have for specifying the credential content in the authorization request, as illustrated in https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-authorization-deails. It add the claims to the credential but with an empty object value.

WDYT?

[David W Chadwick]

As you said in our private conversation, a flat claims list cannot indicate the actual claims needed due to the nested structure of the credential subject object (unless you use the dotted notation). The alternative would be to send one JSON object that mirrored the structure of the full credential subject object but only included the properties that are being requested. The end result is the same. It's just a question of which encoding mechanism is best/easiest for the wallet and issuer to process.

[David W Chadwick]

Note that we already have examples of the ‘type’ claim occurring at multiple levels in a credential so simply stating the claim ‘type’ is ambiguous. Does it mean credentialSubject.certificate.type or credentialSubject.addresses.type etc.

[Kristina Yasuda]

marking this pending close. this issue should have been closed when we closed PR #222, which has lengthy conversations on this topic.

[David W Chadwick]

I would like us to discuss this issue at the next meeting please

[David W Chadwick]

@torsten I have now seen the latest proposed structure in the authz details that you pointed to, and this does contain the full JSON object construction. So I agree that this can be used.

[Kristina Yasuda]

addressed