Authorization Details claims

[c2bo]

The Appendix introduces specific claims for Authorization Details for mdoc and sd-jwt vc type credentials. For both of them a new claim claims is introduced as

claims: OPTIONAL. Object as defined in Appendix A.3.2 excluding the display and value_type parameters. mandatory parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).

I was wondering if this should be extended to also allow expected values inside the claim. This would allow the Wallet to signal expected claims which might help for cases where there are several options of the same type of credential to be issued.

A good example would be a bank where one user might be the owner of different bank accounts within that one bank and would like to get a credential for a specific one. This way authorization_details could be leveraged to signal the expected one.

We could introduce a new optional claim expected_value like this:

[
    {
        "type": "openid_credential",
        "format": "vc+sd-jwt",
        "vct": "SD_JWT_VC_example_in_OpenID4VCI",
        "claims": {
            "given_name": {
                "expected_value": "SomeName"
            }
        }
    }
]

[Sakurann]

A good example would be a bank where one user might be the owner of different bank accounts within that one bank and would like to get a credential for a specific one.

Why would a wallet have information which bank account the user have in mind? It should be the issuer who provides user with an interface to specify which claims should go into the credential if there could be multiple options.

[David-Chadwick]

Why would a wallet have information which bank account the user have in mind? Ans. Because the user is in charge of the wallet and can type the information into it. The user surely knows which bank accounts she has.

[c2bo]

Why would a wallet have information which bank account the user have in mind? It should be the issuer who provides user with an interface to specify which claims should go into the credential if there could be multiple options.

Depends on how you start the flows. If you start from a website, then yes the user should be guided through some form of selection and choose for example the correct banking account. If you trigger the process from for example another App that has relevant information, it might make sense to provide that directly without user interaction.

The issuer would still check if the provided information is correct and matches its internal data but it would provide an alternative way of selection/interaction with the system.

[jogu]

Perhaps a better example would be the wallet wanting to obtain, say, a university degree that matches the user it already has an identity credential for.

[Sakurann]

I am much clearer on the use-case, thank you for clarifying.

I think it was the following suggestion that confused me: I was wondering if this should be extended to also allow expected values inside the claim.

Sounds like something like login_hint authorization request parameter from OIDC could be used for this? I don't see the need for this information to be per claim/per credential?

definition of login_hint: OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

[jogu]

Sounds like something like login_hint authorization request parameter from OIDC could be used for this? I don't see the need for this information to be per claim/per credential?

I don't think login_hint can be used "as is" as it really only expects an email address or phone number, I think passing a given_name or bank account number in login_hint would not really be interoperable. It feels more similar to the OIDC 'claims' parameters to me.

[c2bo]

Yeah, if we are talking about something similar in OIDC, it would probably be the claims Requests Parameter with a requested value (https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests).

[Sakurann]

for the authorization_details in the authorization request, sending specific claim values about the used is a privacy issue, isn't it? the user has not authenticated at the issuer yet, the user has not consented to the issuance of the credential to the issuer, the issuer has not authenticated the wallet yet, but the wallet is already sending PII to the authorization endpoint..? i might be missing something, but does not sound right to me.

PS. I agree, login_hint is probably not the best analogy, because in OIDC it is merely a hint, while expected_value here sounds to be much more than a hint

[Sakurann]

@pmhsfelix do you have this use-case/requirement?

[Sakurann]

labeling 1.1 since my understanding is that this can be done in a backward compatible manner post 1.0