How is User Consent provided

[David W Chadwick]

The user may interact with the credential issuing eco-system via the wallet and give consent to the wallet to accept a credential with certain attributes from the issuer, or the user may interact with the issuer’s web site via a browser and give consent to the issuer for it to load a credential into her wallet. Both modes should be supported, and the swimlane(s) should show the interactions between the user and the credential issuer, either directly or via the wallet.

Furthermore, how does the user know that the credential that has been loaded into the wallet contains exactly the attributes that she consented to? Should we place requirements on the wallet to check this, or to ask the user for a second consent?

[Tobias Looker]

The user may interact with the credential issuing eco-system via the wallet and give consent to the wallet to accept a credential with certain attributes from the issuer, or the user may interact with the issuer’s web site via a browser and give consent to the issuer for it to load a credential into her wallet. Both modes should be supported, and the swimlane(s) should show the interactions between the user and the credential issuer, either directly or via the wallet.

I disagree with supporting a model whereby the wallet is trusted to get the End-Users consent on behalf of the issuer to issue a credential, if the user is going to be authenticated by the provider during the normal OIDC transaction why not just use that opportunity to ask for consent then?

Furthermore, how does the user know that the credential that has been loaded into the wallet contains exactly the attributes that she consented to? Should we place requirements on the wallet to check this, or to ask the user for a second consent?

Im not sure I understand what you are advocating for here, are you saying the wallet must ask for End-User consent after the credential is issued before storing it in their wallet? If so I think this is too prescriptive, some wallets may choose to do this but I dont think it should be normatively required.

‌

[Jeremie Miller]

I’d be supportive of language that is only SHOULDs, such as:

A holder implementation SHOULD have the ability to display every claim in a credential that is being or has been accepted.

A holder implementation SHOULD request consent by displaying the identity of the verifier and all of the claims that will be released.

[Tobias Looker]

I’d be supportive of language that is only SHOULDs, such as:

Yes I would be supportive of this style of normative statement, or instead of SHOULD → RECOMMENDED, however anything stronger from a normative perspective I wouldn’t support.

‌

[David W Chadwick]

I have had more thought about this, concerning the point John raised in the minutes of 11 March (i.e. what if the issuer issues more or less credentials). The trust model can only be that the issuer is trusted by the user/wallet, otherwise all bets are off. Issuing less claims is less of a problem than issuing more claims than the user consented to. Considering the complexity of VCs, with their ability to be infinity extended, both in standard properties such as Terms Of Use, and Evidence, and in new (as yet undefined properties) then an Issuer could easily bury additional information in a VC that the wallet is not able to display to the user. In this way it is possible to surreptitiously pass claims from the issuer to the RP without the user/wallet being aware of the precise contents (e.g. the property values could be encrypted or passed using steganography in a jpeg). Therefore I think it should be outside the scope of OIDC to cater for an untrustworthy issuer, and the security section should say that it is possible for an untrustworthy issuer to pass additional information to the RP by burying/obfuscating it in the issued credential.

[Tobias Looker]

I have had more thought about this, concerning the point John raised in the minutes of 11 March (i.e. what if the issuer issues more or less credentials). The trust model can only be that the issuer is trusted by the user/wallet, otherwise all bets are off. Issuing less claims is less of a problem than issuing more claims than the user consented to. Considering the complexity of VCs, with their ability to be infinity extended, both in standard properties such as Terms Of Use, and Evidence, and in new (as yet undefined properties) then an Issuer could easily bury additional information in a VC that the wallet is not able to display to the user. In this way it is possible to surreptitiously pass claims from the issuer to the RP without the user/wallet being aware of the precise contents (e.g. the property values could be encrypted or passed using steganography in a jpeg). Therefore I think it should be outside the scope of OIDC to cater for an untrustworthy issuer, and the security section should say that it is possible for an untrustworthy issuer to pass additional information to the RP by burying/obfuscating it in the issued credential.

+1 I agree with this sentiment and that we should simply add a comment in the security section about this.

‌

[Kristina Yasuda]

I agree with the above sentiment, but I think “catering for untrustworthy issuer“ is more related to the Issue #1451, which can be in security considerations. I this consent issue is separate and I would still be supportive of a clarification language around Issuer getting user consent vs wallet getting it on behalf of the issuer.

[Kristina Yasuda]

Please review PR #137.

btw, the current text is already very clear about consent, see

(4.3) The issuer asks the user for consent to issue the requested credentials.

[Torsten Lodderstedt]

I suggest to change this language to “The issuer MAY ask the user for consent at this point if required to issue the requested credential.”. As already noted at PR 137, consent is a legal thing and it can be collected in a number of ways (by the issuer by the wallet, by way of a terms of service agreement, by regulation). We should not force a certain way or even recommend one but support all possible modes.

[David W Chadwick]

@Torsten. I agree that consent can be provided in a number of ways and we should not mandate (or even favour) any particular way. We just need to have text in the spec that makes this clear.

[Kristina Yasuda]

see PR #232 for full discussion.

no consent of the WG to support this additional consent model. Noting that this new consent model requested by DavidC. does not exist in the OIDC4VCI. (there is a consent mechanism in OIDC4VCI - it does not have a protocol messages for consent defined)