1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

[ID-2] Mandatory vs optional credential claims

Issue #1451 resolved
Tobias Looker created an issue

Some credential types, such as mDL have the concept of mandatory claims which means an mDL issued without these mandatory claims could be said to be invalid, we should introduce this concept in this draft to prevent a situation where an mDL could be issued with less than its mandatory claims.

Comments (28)

  1. Kristina Yasuda

    I think it is Issuer’s responsibility to issue a certain credential type (like mDL) with all the mandatory claims. Regarding the optional claims, we could utilize claims/authorization_details parameters to enable an RP to request a subset of optional claims.

  2. David W Chadwick

    I think your issuing model should be similar to that of issuing X.509 PKCs. ie. the user can request a certain set of attributes, but the issuer is responsible for deciding which set the user actually gets and can ignore user requests (i.e. not issue what is being requested) or modify user requests (i.e. change the value the user is requesting) or supplement user requests (i.e. add mandatory attributes to those the user is requesting). In our implementation the user makes a request, and the VC Issuer either issues exactly what has requested, or tells the user “this is what you will get, do you consent or not”. So in the end both user and Issuer agree or no VC is issued.

  3. Tobias Looker reporter

    I find that model problematic and potentially prone to implementation issues. What if the wallet didn’t want a credential with those claims and would not have executed the request if that were going to be the outcome, how does the End-User know what the wallet requested from the issuer vs what the issuer was able to provide, feels like an overly complicated consent process would be needed to accomodate it? Why do we need to account for this divergence between what a wallet requests vs what an issuer actually provides?

  4. Tobias Looker reporter

    Can you point to some examples of X.509 based systems where the requestor requests a certificate with certain information and gets one with other information instead?

  5. David W Chadwick

    Sorry let me restate the model more clearly. The issuer is always responsible for deciding what is in a certificate. The user requests which contents it would like, but the issuer can follow this request or not (i.e. ignore, change or add attributes). If the issuer conforms to the user’s request it issues the certificate, otherwise it fails and informs the user of the required changes (ignored, changed or added values). The user can then consent to these changes by issuing a modified request with the new attributes, or refuse the changes, end the session and not obtain a certificate. I do not think this model is problematic or prone to implementation errors.

    ‌

  6. Tobias Looker reporter

    The issuer is always responsible for deciding what is in a certificate

    I agree with this statement

    The user requests which contents it would like, but the issuer can follow this request or not (i.e. ignore, change or add attributes

    I dont really agree with this statement, the wallet makes the request on behalf of the end user to the issuer, so they are part of this flow too, if the issuer decides to issue something else, how does the wallet become aware of this? The potential for returning a different credential to the wallet then what was requested I dont think is a viable approach, if the issuer cannot satisfy the request the safest option is to return nothing or an error explaining what has occured.

    ‌

  7. David W Chadwick

    @Tobias. Please read my response again. You will see that I am not advocating the approach that you think I am. The issuer does not issue a different credential to that requested. It tells the user the changes that are required. The user can then consent to these changes by issuing a modified request with the new attributes, or refuse the changes.

  8. Tobias Looker reporter

    No I understand your response, I think you are missing what I was saying which is that its insufficient in my mind to just get End-User consent for a change in the scope of a credential request mid-flight, what about the wallet? Effectively the wallet starts the flow sending an issuance request, requesting credential X with claims Y on behalf of the End-User. In your model during the User Auth and consent phase it sounds like this credential and its claims could change, so the wallet is actually returned credential Z with claims X. This is an issue because the wallet requests one thing and get something entirely different, it doesn’t matter that the user consented to it if the wallet is not expecting it. An Issuance flow is not a two party model (Issuer and End-User) its three party (Issuer, Wallet and End-User) all have a part to play and all must be fully aware of the informational flow going on.

    ‌

    ‌

  9. David W Chadwick

    Exactly so. This is a three party exchange with the wallet in the middle. Again my post says ‘the user consents to these changes.. or refuses them’ so in our implementation the wallet shows the user the revised credential (note. not verifiable credential) and the user can consent to this or not.

  10. Tobias Looker reporter

    I think the disconnect here is that there are different flows involved in your protocol around who talks to who when in comparison to how oidc4vci works. For example getting End-User consent around what is the resulting credential is going to be should not be collected or proxied through the wallet it should be direct communication between the End-User and Issuer.

  11. Tobias Looker reporter

    I also disagree with the framing of the wallet being “in the middle” of this exchange, the wallet is requesting party on behalf of the End-User, the issuer is the provider of the credential and the End-User is in the middle authorising and giving consent for the exchange to occur.

  12. David W Chadwick

    Then I think your mental model does not conform to the W3C VC model in which the holder (user) has wallet software acting on its behalf

  13. David W Chadwick

    “direct communication between the End-User and Issuer” can never take place as the user needs software to act on its behalf with the issuer (which is also enacted by software)

  14. Tobias Looker reporter

    Then I think your mental model does not conform to the W3C VC model in which the holder (user) has wallet software acting on its behalf

    No to the contrary I do believe in this model however you have to qualify further “what” the wallet software has authority to do on behalf of the User, the delegation between End User → Wallet is not limitless.

    “direct communication between the End-User and Issuer” can never take place as the user needs software to act on its behalf with the issuer (which is also enacted by software)

    Correct the interaction with End-User is still always mediated by software but my point is that this mediation does not have to pass through the wallet for things like consent and in fact doing this vastly complicates the system because now the Issuer has to trust the wallet to obtain the End User consent correctly. For instance consent to release claims in OpenID connect is usually obtained via a web page controlled by the provider, I believe this model is far less complex and extends well to service credential issuance journeys. It also importantly allows an issuer to ask “do you want to issue a credential into wallet provider x?”.

    ‌

  15. David W Chadwick

    This has been a very good exchange, thankyou, and it shows the importance of the mental models that people are using. When they are different, we seem to disagree on issues. But when we realise that we have different mental models then it is easier to resolve issues and better understand each other. I think it would be very good for all the VC related specs to have a set of swimlanes, one set for each of the valid mental models, so that readers can understand the different protocol flows that each model requires.

    FYI, we use the FIDO protocol flow in our VC issuing as this has the advantage of a very secure protocol between the VC Issuer and Wallet and a ceremony between the wallet and the human user, in which the ceremony is controlled by protocol elements set by the VC issuer when talking to the wallet.

  16. Tobias Looker reporter

    This has been a very good exchange, thankyou, and it shows the importance of the mental models that people are using.

    Likewise was very good teasing out differing mental models.

    I think it would be very good for all the VC related specs to have a set of swimlanes, one set for each of the valid mental models, so that readers can understand the different protocol flows that each model requires.

    +1 IMO most of the mental model that OIDC4VCI leans on is supplied through OpenID Connect Core, however the spec also does have some ASCI art that describes the flow.

  17. Tobias Looker reporter

    While the conversation above is great for sharing different mental models it is not entirely related to the original issue title and description, to Kristina’s original feedback I think we agree on the outcome, if a provider provides a credential where certain claims MUST always be present then a situation MUST never arise where the issuer issues a credential without the mandatory claims. Beyond that I think there are a couple of things that would be useful to decide in regards to how this constraint is communicated and enforced with an RP/wallet. For example

    • Should we update the credential manifest / credential metadata published at the openid discovery endpoint to group mandatory vs optional claims (with the implication being that a wallet can only negotiate the presence of optional claims in resulting credentials?)
    • Should we update the claims request object syntax language to note that claims requested here only apply to optional claims and that any mandatory claims associated to the request credential type will always be present?

    ‌

  18. David W Chadwick

    Issuers can publish the JSON schema for their issued credentials and this already says which properties are mandatory and which are optional. It can also contain other credential information such as terms of use, evidence etc, so as to give a complete picture of the issued credentials.

    I think the claims request object should contain both mandatory and optional attributes because the user needs to be aware of what is being requested. (I know that the GUI is not the same as the protocol, but missing mandatory attributes from the protocol might end up with wallet GUIs only showing the optional ones).

  20. Oliver Terbu

    Is this issue still active? IMO, if an issuer issues an ISO mDL, then it is the issuer’s responsibility to make sure it is compliant with the ISO standard (including the mandatory fields) consequently out-of-scope of the issuance spec.

  21. Kristina Yasuda

    I agree. so no need for any clarification in the spec or one sentence in the implementation details section?

  22. David W Chadwick

    This issue is still active because the related PR #137 is still active. I have raised an issue in the W3C VC WG for them to determine if a selectively disclosed VC received by an RP, which only contains a subset of claims, is conformant to the schema. We could for example make every claim in a VC optional (in the schema) and then all SD VCs would be conformant. (ISO mDL is an interesting case because the RP has no idea which claims are present as they are all blinded, so it cannot determine if an SD mDL conforms or not to the schema because it cannot tell if all the mandatory claims are there or not :-).

  23. David W Chadwick

    This issue was discussed at the VC WG meeting on 31 Aug 22, ( https://github.com/w3c/vc-data-model/issues/890) and the notion of a “presentationSchema” was raised, which could be more useful to the verifier than the credentialSchema, due to selective disclosure i.e. what the verifier recieves may very well have many of the mandatory attributes missing (either present but opaque as in mDL, or not present as in ZKP). So the credentialSchema, saying which attributes are mandatory and which are optional, is of no use to the verifier. But the verificationSchema might be. So it does not really matter if the issuer issued a credential with missing mandatory attributes if the verifier does not want them, as it wont request them. What really matters is that:

    a) the presented credential contains only those claims that the verifier has requested and that the issuer says must be present in each presented credential (if any)

    b) the presented credential does not contain claims that are not allowed by the credentialSchema (e.g. a university degree credential contains bank account details) as the issuer is not authoritative for them (e.g. as determined by the federation that specified the credentialSchema).

    So I think the verification processing rules should do the following:

    a) check that the presented claims are allowed to be there by the credentialSchema (ignoring mandatory/optional flags) and that none are present that are not mentioned in the credentialSchema

    b) check that the presented claims contain those that are mandated in the “presentationSchema” if this is defined by the W3C VC WG.

  24. gffletch

    My thought is that if a client wants to specify claims within a credential type, they only apply to the optional claims. If a request contains a claims specification that is for a mandatory field (to the credential type) then it is ignored. All mandatory claims of the requested credential type will be returned.

    This does create some cases where “over-sharing” can occur, but it is consistent and in line with current OpenID implementations around claims. This is my vote for the first implementor’s draft.

  25. Michael Jones

    As discussed during the 3-Oct-22 working group call, in OpenID Connect RPs request claims, OPs provide claims based on the requested claims, and the RP decides how to proceed based on the actual claims returned. Note that the requested and returned claims may be quite different for many reasons, including whether values from them exist and whether consent to release them was given.

    This loosely coupled model, in which it not an error to be unable to return all the requested claims, has proven its value over the past decade. Indeed, that gives the RP the most actionable information. For instance, then it can then give the best error messages possible, even when further processing isn't feasible.

    Returning errors from the issuer is the least useful thing to do, from an ecosystem perspective. Even partial results are far more useful.

    Not being able to return exactly what was requested is a normal case and should not result in errors.

  26. David W Chadwick

    I can live with the above model. The problem at the moment is that the RP has no way of requesting any claims, optional or mandatory. It can only request a credential type. If we can add the requested claims from the type to the issuing protocol this would satisfy the issue.

  29. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Component
Credential Issuance
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!