Proposal to use independent claims for each VC/VP proof type

[Sakurann]

• Added four JWT Claims to represent W3C Verifiable Credentials objects
• Added vp_jwt, vp_ldp examples of SIOP response when W3C Verifiable Credentials objects are returned with JWTs
• Added vp_jwt, vp_ldp examples of UserInfo response when W3C Verifiable Credentials objects are returned as JSON claims
• vc_jwt, vc_ldp option examples are missing
• took our vp_token related text
• edited the request part, moved it to the end for the following reasoning:
  • There are multiple candidates for requesting verifiable presentations and verifiable credentials using OpenID Connect flows: Edmund's Aggregated Claims draft, DIF Presentation Exchange, below draft, and probably others. This would be a natural next step after defining claims, and agreeing on the request syntax should be separate from agreeing on the usage of the above four claims.

[tlodderstedt]

Please see my comments. Additionally, it seems significant parts of the main revision re are still missing. Please integrate again.

[tlodderstedt]

It does more than that as it includes syntax for requesting vcs and vps and will also contain processing rules. What's wrong with the existing text?

[Sakurann]

I think syntax for requesting vcs and vps should be different from defining the claims. as iterated in the PR comment

[tlodderstedt]

Sure. Requesting something is different from representing something. However, I intend to come up with at least one reasonable end 2 end solution. That's important for implementers and it is the basis for a stable and reasonable concept. Just discussion claims in isolation is not sufficient because those claims serve a purpose. There is not a single JWT claim so far defined in isolation. verified_claims, for example, is part of OpenID 4 Identity Assurance. It would never have gotten the maturity it has now without the context. Does this mean verified_claims cannot be used in other contexts? Of course not! We use it heavily in token introspection responses.

I suggest to first of all discuss this topic and then propose potential changes to our draft in a separate PR. So far, we have discussed to change the representation of the VCs/VPs from vp_token and id token as VP to universal claims in ID token (and other artefacts). We agreed to continue this discussion and you took the task to make a PR as basis for further discussions. The current PRs goes way beyond what we have discussed. It especially proposes removal of text that I consider important and have put significant work in. I don't agree with those changes.

[Sakurann]

The current PRs goes way beyond what we have discussed. It especially proposes removal of text that I consider important and have put significant work in. I don't agree with those changes.

yes, I understand. It felt wrong when doing this PR. Let me revert

[tlodderstedt]

I don't get the value of the differentiation between JWTs and JSON claim set. These claims can be used in any JSON based object, right? The payload of a JWT is a JSON claim set as well, isn’t it?

[Sakurann]

The UserInfo Endpoint uses JWT claims in JSON, but without the response being a JWT. It's the body of a JWT, without the crypto parts.

[tlodderstedt]

I think we are saying the same. I would suggest to come up with more generic text like we have in eKYC.

A verified_claims element can be added to a OpenID Connect UserInfo response or an ID Token.

OAuth Authorization Servers can add verified_claims to access tokens in JWT format or Token Introspection responses, either in plain JSON or JWT-protected format.

An OP or AS MAY also include verified_claims in the beforementioned assertions as aggregated or distributed claims (see Section 5.6.2 of the OpenID Connect specification [OpenID]).

PS: a UserInfo response can also be a JWT if it is signed and/or encrypted ;-).

[Sakurann]

tried to incorporate proposed generic text :)

[tlodderstedt]

feels better placed in a section about request processing

[tlodderstedt]

I don't particularly like this polymorphism.

[Sakurann]

you fundamentally object to the choice of the four claims?

[tlodderstedt]

This comment is about the polymorphic definition of the claims as object or array. It is inline with the way aud is defined, but it creates unnecessary complexity where an array is sufficient.

My next comment raises the question whether the design approach is the best solution and proposes an alternative. There are pros and cons of both proposals that we should discuss and assess based on use cases and other requirements informing this discussion.

[awoie]

I agree that the polymorphism also caused some issues with aud implementations in the past. I'm happy to just say it is an array.

[tlodderstedt]

I'm not sure whether we should define 4 different claims. I feel a single claim with metadata is better suited.
Something like this:

   "verifiable_presentation":{
      "format":"jwt",
      "proof":"external",
      "presentation":"ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="
   }

This gives implementors the ability to support further formats, like CBOR or AnonCreds. I would also envision implementations to add further data to the structure as needed, e.g. the metadata we talked about yesterday for carrying additional metadata for hash-based VCs in JWT-format to allow for selective disclosure.

[awoie]

If we used the metadata approach, then we should really think whether it makes sense to borrow the presentation_submission property from DIF PE:

"presentation_submission": {
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "descriptor_map": [
      {
        "id": "banking_input_2",
        "format": "jwt_vc",
        "path": "$.verifiableCredential[0]"
      },
      {
        "id": "employment_input",
        "format": "ldp_vc",
        "path": "$.verifiableCredential[1]"
      },
      {
        "id": "citizenship_input_1",
        "format": "ldp_vc",
        "path": "$.verifiableCredential[2]"
      }
    ]
  }

The path would just point to the verifiable_presentation claim in the id_token.

The only problem is that definition_id is mandatory and refers to the presentation_definition in the request. A minimal presentation_definition looks as follows:

"presentation_definition": {
    "id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "input_descriptors": [
      {
        "id": "wa_driver_license",
        "schema": [{
            "uri": "https://licenses.example.com/business-license.json"
        }]
      }
    ]
}

[Sakurann]

I am in favor of the array approach with several claims that address most needed representations, which would be more simple. Since I do not think we expect wide adoption of new proof formats other than JSON/JSON-LD in the mid-term future, four claims should fulfill the implemetations' needs.

Having said that, I think we agreed to start a separate in-depth document comparing the two approaches - four claims vs. one claim with metadata.

[tlodderstedt]

Please reintegrate the request section and the request examples in its previous places. I would then adopt them to fit the new claims.

[Sakurann]

yes, updated

[awoie]

i guess we need to reiterate on the query request format a bit.

[awoie]

I agree that the polymorphism also caused some issues with aud implementations in the past. I'm happy to just say it is an array.

[awoie]

I think the claims are a good starting point but this particular spec should also talk about the protocol level, i.e., requesting Verifiable Presentations. Note, the DIF Presentation Exchange spec only contains examples for OIDC but there is no normative reference. Someone and I propose we do this in the course of this spec, should create such a normative reference by utilizing the proposed claims.

[Sakurann]

yes, agreed. per the call we just had, I think the next step is to show how VP/VCs will be requested using

• OIDC claims parameter
• DIF Presentation Exchange
• Aggregation claims draft
• OIDC ekyc-ida?
• Credential Provider draft?

[tlodderstedt]

Most of the example you gave us the claims parameter in different flavours.

The aggregation claims draft doesn’t cover VP/VC. It uses the claims parameter to let an OP request claim sets at an aggregated claims provider for further use towards a RP as aggregated claims.

OIDC ekyc-ida uses the claims parameter to request verified_claims. That's a different topic but we should borrow the pattern. We perhaps can also utilize eKYC syntax, depending which way we go re representation and what the intended scope is.

Credential Provider draft uses a scope to request issuance of credentials and is silent on how the OP (credential provider) determines the credential types. From the conversations with Adam und Tobias we learned the idea is to a single OP per credential type to issue. I think this model won't scale. I think credential representation and how to request credentials should be aligned with this draft.

I think we've got two options: claims or DIF PE

[tlodderstedt]

the section is still just a small part of what exists in the main revision.

For example, it misses the ability to request a subset of claims.

[tlodderstedt]

request example is missing

[Sakurann]

added

[tlodderstedt]

Ambiguous request - it shall either put the vp_ldp into an "id_token" or "userinfo" context.

[Sakurann]

requesting "vp_ldp" using "userinfo". Added reqesting "auth_time" using "id_token" to illustrate how these can work together.

[tlodderstedt]

request syntax definition is incomplete and auth code example needs fix

[tlodderstedt]

That‘s all claims parameter based. The only exception is PE. I created a ticket #22 Kristina ***@***.***> schrieb am Fr. 9. Apr. 2021 um 18:33:

…

***@***.**** commented on this pull request. ------------------------------ In README.md <#20 (comment)>: > -## Requesting Verifiable Presentations yes, agreed. per the call we just had, I think the next step is to show how VP/VCs will be requested using - OIDC claims parameter - DIF Presentation Exchange - Aggregation claims draft - OIDC ekyc-ida? - Credential Provider draft? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQFJT6WWGVSOFBE7HCFY3TH4T45ANCNFSM42UGEJKA> .

[Sakurann]

I am not sure Aggregated Claims syntax really makes sense. Claims would have to be requested using their pre-agreed names in the request which does not really work with VPs in JSON-LD as it dilutes the purpose of @context.

Aggregated Claims response example:

{
  "_claim_names": {
       "address": "src1",
       "phone_number": "src1"
     },
   "_claim_sources": {
     "src1": {"vp_jwt": "ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="}
   }  

[Sakurann]

or maybe it does, OP would just take the claim name out of the schema

[tlodderstedt]

the standard aggregated claims syntax does only allow you to refer to the top level claims provided in the aggregated claim set. In your example, this would be:

{
  "_claim_names": {
       "vp_jwt": "src1"
     },
   "_claim_sources": {
     "src1": {"vp_jwt": "ewogICAgImlzcyI6Imh0dHBzOi8vYm9vay5pdHNvdXJ3ZWIub...IH0="}
   }

telling the RP where to look for the vp_jwt claim.

In order to support multiple occurences (multiple VPs), one could adopt the syntax extension we did in eKYC (https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-verified_claims-delivery). We also allow for an array of sources.

[tlodderstedt]

I added a couple of comments.

[tlodderstedt]

this syntax is not covered by the syntax definition. I suggest to use the example fron above with the credential_types element. We can extend the query syntax once we have come to a consensus re claims vs container vs ADS vs ...

[Sakurann]

for vp_jwt changed to response_type; for vp_ldp, it is response_type + claims

[tlodderstedt]

see above

[tlodderstedt]

I suggest to show associated claims parameter example and token response example in a row.

vp_jwt

• claims
• token response
• vp

vp_ldp

• claims
• token response
• vp

[Sakurann]

vp is quite different ,but in claims, vp_jwt simply changes to vp_ldp and token response is the same

[Sakurann]

restructured as above

[tlodderstedt]

I don't think we need this section any longer

[tlodderstedt]

You mean OpenID Connect OPs? I'm asking since OAuth Authorization Servers issue access tokens and may expose token introspection but don't issue ID Tokens or have a userinfo endpoint.

[Sakurann]

good catch, thank you. I meant OPs.

[tlodderstedt]

I don't fully get why we need the following 3 sentences since the real definition is given in "ID Token Extensions".

I suggest to remove the additional heading "ID Token Extensions" and move (a simplified version of) the first 3 sentences to the end of the section.

Text could be:

"Those claims can be added to ID Tokens, Userinfo responses as well as Access Tokens and Introspection response. "

[tlodderstedt]

Most of the example you gave us the claims parameter in different flavours.

The aggregation claims draft doesn’t cover VP/VC. It uses the claims parameter to let an OP request claim sets at an aggregated claims provider for further use towards a RP as aggregated claims.

OIDC ekyc-ida uses the claims parameter to request verified_claims. That's a different topic but we should borrow the pattern. We perhaps can also utilize eKYC syntax, depending which way we go re representation and what the intended scope is.

Credential Provider draft uses a scope to request issuance of credentials and is silent on how the OP (credential provider) determines the credential types. From the conversations with Adam und Tobias we learned the idea is to a single OP per credential type to issue. I think this model won't scale. I think credential representation and how to request credentials should be aligned with this draft.

I think we've got two options: claims or DIF PE

[tlodderstedt]

definition for "userinfo" is missing

[Sakurann]

as in https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter?

[Sakurann]

I think it should be "The OP shall respond with a presentation containing credentials of the listed types."

As the text states now, it is misleading that array is how a client asks for any one​ of these types to be satisfied (not all​ of them)