Define claims display description and claims path query #276

danielfett · 2024-02-20T18:51:44Z

Mainly fixes #266 based on https://vcstuff.github.io/sd-jwt-vc-types/danielfett/fix-claims/draft-fett-oauth-sd-jwt-vc-types.html#section-8

Also Fixes #272
Also Fixes #271

mickrau

After review in our team: In principle, we like the proposal and support it.
We left two comments regarding claims object display property and value_type.

mickrau · 2024-02-21T09:27:09Z

examples/credential_metadata_sd_jwt_vc.json

-            }
+                {"path": ["email"]},
+                {"path": ["phone_number"]},
+                {"path": ["address", "street_address"]},


We would like to give display properties to an object of claims. The wallet could use this property when collapsing the object's claims in the UI. Is this possible and would the following be the right way?
If so, this should be part of an example.

{ "path": ["address"], "display": [ { "name": "Address", "locale": "en-US" }, { "name": "Adresse", "locale": "de-DE" } ], "value_type": "object" }, {"path": ["address", "street_address"]},

+1 for this! I think supporting this is mandatory for having a clear and defined way to present this kind of data to the user. Let's use the example from your documentation and extend it with an arbitrary example:

... "address": { "street_address": "42 Market Street", "city": "Milliways", "postal_code": "12345" }, ... "work_address": { "city": "Berlin", ... },

I would expect/imagine this to be displayed in the ui similar to this:

place of residence +- street: 42 Market Street +- city: Milliways `- post code: 12345 .... place of work +- city: Berlin +...

mickrau · 2024-02-21T09:42:31Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -1987,13 +1989,7 @@ The following additional Credential Issuer metadata parameters are defined for t

 * `credential_definition`: REQUIRED. Object containing the detailed description of the Credential type. It consists of at least the following two parameters:
  * `type`: REQUIRED. Array designating the types a certain Credential type supports, according to [@VC_DATA], Section 4.3.
-  * `credentialSubject`: OPTIONAL. Object containing a list of name/value pairs, where each name identifies a claim offered in the Credential. The value can be another such object (nested data structures), or an array of such objects. To express the specifics about the claim, the most deeply nested value MAY be an object that includes the following parameters defined by this specification (other parameters MAY also be used):
-      * `mandatory`: OPTIONAL. Boolean which, when set to `true`, indicates that the Credential Issuer will always include this claim in the issued Credential. If set to `false`, the claim is not included in the issued Credential if the wallet did not request the inclusion of the claim, and/or if the Credential Issuer chose to not include the claim. If the `mandatory` parameter is omitted, the default value is `false`.
-      * `value_type`: OPTIONAL. String value determining the type of value of the claim. Valid values defined by this specification are `string`, `number`, and image media types such as `image/jpeg` as defined in IANA media type registry for images (https://www.iana.org/assignments/media-types/media-types.xhtml#image). Other values MAY also be used.


The types array and object should also be mentioned explicitly and used in examples.
How can the type of array elements be determined?

{"path": ["nationalities"], "value_type": "array"} {"path": ["nationalities", null], "value_type": "string"}

paulbastian · 2024-02-22T16:37:14Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -2215,7 +2194,7 @@ The following is a non-normative example of an object comprising the `credential
 The following additional claims are defined for authorization details of type `openid_credential` and this Credential format.

 * `vct`: REQUIRED. String as defined in (#server-metadata-sd-jwt-vc). This claim contains the type values the Wallet requests authorization for at the Credential Issuer. It MUST only be present if the `format` claim is present. It MUST not be present otherwise.
-* `claims`: OPTIONAL. Object as defined in (#server-metadata-sd-jwt-vc) 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).
+* `claims`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).


Suggested change

* `claims`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).

* `claims`: OPTIONAL. An array of claims path queries as defined in (#claims-path-query). The parameter is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued containing exactly those claim(s).

paulbastian · 2024-02-22T16:41:54Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -2005,7 +2001,7 @@ The following additional claims are defined for authorization details of type `o

 * `credential_definition`: OPTIONAL. Object containing a detailed description of the Credential consisting of the following parameter:
  * `type`: OPTIONAL. Array as defined in (#server-metadata-jwt-vc-json). This claim contains the type values the Wallet requests authorization for at the Credential Issuer. It MUST be present if the claim `format` is present in the root of the authorization details object. It MUST not be present otherwise. 
-  * `credentialSubject`: OPTIONAL. Object as defined in (#server-metadata-sd-jwt-vc) 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).
+  * `credentialSubject`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).


Suggested change

* `credentialSubject`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).

* `credentialSubject`: OPTIONAL. An array of claims path queries as defined in (#claims-path-query). The parameter is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued containing exactly those claim(s).

I don't think that referencing this way works very well given how the #claims-description and #claims-path-query sections are written currently.

Could we start with the #claims-path-query section defining only path and then follow up with the #claims-description building on top?

Probably, yeah. My comment here was just to say that this change (and others like it) doesn't work without changes to the referenced sections. So can't be accepted/committed in isolation. @danielfett is likely already aware though so sorry for the noise :/

paulbastian · 2024-02-22T16:44:57Z

openid-4-verifiable-credential-issuance-1_0.md

-    * `display`: OPTIONAL. Array of objects, where each object contains display properties of a certain claim in the Credential for a certain language. Below is a non-exhaustive list of valid parameters that MAY be included:
-        * `name`: OPTIONAL. String value of a display name for the claim.
-        * `locale`: OPTIONAL. String value that identifies language of this object represented as language tag values defined in BCP47 [@!RFC5646]. There MUST be only one object for each language identifier.
+* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a certain `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims description objects as defined in (#claims-description). The namespace applies to the claims described in the array of claims description objects.


Suggested change

* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a certain `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims description objects as defined in (#claims-description). The namespace applies to the claims described in the array of claims description objects.

* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims description objects as defined in (#claims-description). The namespace applies to the claims described in the array of claims description objects.

paulbastian · 2024-02-22T17:03:26Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -2161,7 +2146,7 @@ The following is a non-normative example of an object containing the `credential
 The following additional claims are defined for authorization details of type `openid_credential` and this Credential format.

 * `doctype`: OPTIONAL. String as defined in (#server-metadata-mso-mdoc). This claim contains the type value the Wallet requests authorization for at the Credential Issuer. It MUST only be present if the `format` claim is present. It MUST not be present otherwise. 
-* `claims`: OPTIONAL. Object as defined in (#server-metadata-sd-jwt-vc) 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).
+* `claims`: OPTIONAL. Object as defined in (#server-metadata-mso-mdoc), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).


Suggested change

* `claims`: OPTIONAL. Object as defined in (#server-metadata-mso-mdoc), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).

* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims path queries as defined in (#claims-path-query). The parameter is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued containing exactly those claim(s). The namespace applies to the claims described in the array of claims description objects.

pmhsfelix · 2024-02-22T17:28:38Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -2236,6 +2215,118 @@ The following is a non-normative example of a Credential Request with Credential

 The value of the `credential` claim in the Credential Response MUST be a string that is an SD-JWT VC. Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

+# Claims Description {#claims-description}
+


Currently the claims description object described in this section is being used for both:

the metadata (information produced by the issuer).

authorization_details entries (RAR) and credential request (information produced by the wallet), where the value_type and display keys cannot be used.

Instead of having a single object model, I believe it would be preferable to have two distinct object model sections, both sharing the path definition. IMO, the advantages are:

We can grow each object model independently. For instance, in the future we can add policy information to the metadata model, without needing to explicitly forbid those new elements on RAR and credential requests.

Have better descriptions for each key. For instance, even if the mandatory key appears on both, we could have distinct fine-tuned descriptions for each case. Currently the mandatory description text only applies to its use on the metadata and the meaning of mandatory on RAR and credential requests needs to be inferred.

Hi Pedro, this is almost what may suggestions do. I'm building authorization_details only on Claims Path Query instead of Claims description

pmhsfelix · 2024-02-22T17:49:37Z

openid-4-verifiable-credential-issuance-1_0.md

-          * `name`: OPTIONAL. String value of a display name for the claim.
-          * `locale`: OPTIONAL. String value that identifies language of this object represented as language tag values defined in BCP47 [@!RFC5646]. There MUST be only one object for each language identifier.
-* `order`: OPTIONAL. Array of the claim name values that lists them in the order they should be displayed by the Wallet.
+  * `credentialSubject`: OPTIONAL. An array of claims description objects as defined in (#claims-description).


The use of an array of claim description objects now allows for multiple contradictory descriptions of the same claim, which I believe was not possible before.
E.g.

[ {"path": ["nationalities"], "mandatory": true}, {"path": ["nationalities"], "mandatory": false} ]

We should clarify how a consumer should react to those cases:

Reject the array (e.g. reject the authorization request is this happens on inside authorization_details)?

Only consider the first one entry?

Merge the properties of both entries (which may only make sense for some cases)?
With arrays, these collisions may be a bit more subtle.
E.g. How should this be handled on an authorization request?

[ {"path": ["nationalities", 0], "mandatory": true}, {"path": ["nationalities", null], "mandatory": false} ]

Does this mean the nationalities array can have one or more elements.

Finally, we could have entries suggesting different structure (and not only different properties), such as

[ {"path": ["nationalities", 0], "display": {...}}, {"path": ["nationalities", "country"], "display": {...}} ]

The first entry indicates that nationalities is an array. The second entry indicates nationalities is an object.

The first and second example show points we indeed need to address. The third one should be taken care of by the current processing rules already.

peppelinux · 2024-02-22T19:02:34Z

examples/authorization_details_ldp_vc.json

-                "family_name": {},
-                "degree": {}
-            }
+            "credentialSubject": [


credentialSubject -> credential_subject

If the current evolution of this project introduces breaking changes, this presents an opportune moment to standardize naming conventions across the board. This could mean adopting snake_case.

True. I had the same thought. Although I'm inclined to go for claims instead.

Microsoft just finished implementing with 'credentialSubject'. Given this is more of an issue of preference, would appreciate if we could keep this camel case.

It appears at times that, on behalf of your employer, you may be hindering the community from considering better specifications. This is a significant concern for the community.

They would need to change quite a lot around the processing anyways, I can't imagine how a single renamed field would add significant cost to that.

Having disparate casings in a standard is frankly infuriating. Don't do that :)

Sakurann

I put a comment in issue #266, but after today's WG call where a concern that this is a very big breaking change was raised, we discussed this internally with Microsoft engineers. We do not currently have use-cases with the claims that have nested structure and array-based solution is too big of a breaking change since we just finished implementing OpenID4VCI based on the text that went to ID-1 voting. So our preference is actually defining the new property nested which may contain descriptions about nested objects (original approach 2).

As a compromise for the existing implementations, my suggestion would be fixing the text that becomes ID-1 with nested approach. and than after ID-1, incorporating the array approach defined in this PR.

openid-4-verifiable-credential-issuance-1_0.md

peppelinux · 2024-02-23T09:13:42Z

openid-4-verifiable-credential-issuance-1_0.md

+A claims path query MUST be a non-empty array of strings, `null` values, or
+non-negative integers. 
+
+A string indicates that the respective key is to be selected, a `null` value


null -> *

would be more understandable ... but, before delving into these details, please consider the gap we have in IETF regarding the JSONPath (or similar approaches) and the requirement to get this standardized before propagating it in the openid specifications, in an unconventional way or in such a way that each specification, for specific needs, produces many narrow implementations with obvious implementation costs for the openid/ietf ecosystem.

As we know, JSONPath outlines a syntax for defining paths within a JSON document to find elements, much like XPath does for XML. It allows for filtering elements based on their attributes, navigating through arrays, and performing operations like slicing arrays.

But "*" would be a string value which would require special rules for claims called * (admittedly, those shouldn't be too common).

JSONPath is a huge dependency. Suddenly, you have regular expressions and other stuff in your credential issuance protocol. Also some security issues, when you implement it incorrectly. And it brings so many things we don't need and would have to define-away...

I don't consider myself a jsonpath lover, I'm wondering if there's the time to define a basic, common and general purpose approach for dealing with all these json handling. I agree to not use JsonPath. I think that we have to define an alternative way, not just tied in openid4vci, something to be reused, and expandend where necessarly.

Considering my concerns about the use of null in claims path queries being potentially misleading and carrying a negative connotation, I'm wondering on an alternative approach with a more intuitive and self-explanatory keyword that aligns with the intended functionality.

we have "special" string like "*" or "".

Or using objects like {"select": "all"} that unfortunately carries more nesting and other concerns.

I was thinking empty string as well instead of null (i think it's reasonable to not allow empty string names) but some libraries will probably also do weird stuff with an empty string.

danielfett · 2024-02-23T10:41:17Z

So our preference is actually defining the new property nested which may contain descriptions about nested objects (original approach 2).

Then we need a new PR for that.

As a compromise for the existing implementations, my suggestion would be fixing the text that becomes ID-1 with nested approach. and than after ID-1, incorporating the array approach defined in this PR.

That would mean two breaking changes.

Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>

cryptphil · 2024-02-23T11:30:07Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -1987,13 +1989,7 @@ The following additional Credential Issuer metadata parameters are defined for t

 * `credential_definition`: REQUIRED. Object containing the detailed description of the Credential type. It consists of at least the following two parameters:


Isn't the sentence "It consists of at least the following two parameters" misleading because credentialSubject is marked as optional, so a valid credential_definition may also only contain one parameter?

I would suggest something like "It consists of at least the type parameter and an optional credentialSubject".

awoie

Need a way to define negative integers for COSE.

awoie · 2024-02-23T13:26:57Z

openid-4-verifiable-credential-issuance-1_0.md

+particular claim in the credential or a set of such claims. This appendix
+defines the syntax and semantics of claims path queries.
+
+A claims path query MUST be a non-empty array of strings, `null` values, or


It would be nice to support negative integers as well since those are used by CWT/COSE claims.

For addressing claims identified by numbers in CWT/COSE, I suggest to use numbers in strings to distinguish them from array elements. WDYT?

We don't yet have any Credential Format Profiles where claims identified by numbers in CWT/COSE. But it might be good to have an approach that would/could work for them anyway. Using numbers in strings to distinguish them from array elements would work but then there's a potential (though unlikely) for ambiguity of a claim identified by the number vs. identified by the number as a string. Maybe the rules here could cover that rare case by just saying to select for both in the case that the credential format allows for it.

Or use an object to represent a number claim name/key something like {"claim-identified-by-number": -257}

Another approach would be to use numbers similar to strings as representing the literal key value to select for. And then a to use single element (or empty arrays) to convey selecting on array element(s). So something like [1] would be used where just 1 is being used now. And an empty [] array (or some variation) could be used in place of how null is being used now.

Something like this, for example, changed from the examples of claims path queries below :

["degrees", [], "type"]: All type claims in the degrees array are selected.
["nationalities", [1]]: The second nationality is selected.

And then when describing or selecting from a CWT, a path of [2] would point to the sub/subject (based on the https://www.rfc-editor.org/rfc/rfc8392.html#section-3.1.2 that defines the Claim Key 2 for the Subject Claim) for example. Some other made up examples showing numbers as the literal key value:

[2]: The subject of the CWT (or SD-CWT VC someday maybe) is selected.
[-65599, -85522]: The nested private CWT claim at -65599 & -85522
["org.someplace.1234.9", 2] A subject claim nested in a namespace

Another approach would be to use a different property instead of path. Perhaps the simplest option would be to use something like path_cbor that could then contain negative integer values?

I like this proposal, in particular using [] instead of null as a wildcard

I don't know it there might be issues with some implementations, as the ones mentioned for "". I can say that in my implementations I can handle void instanced of arrays or strings without any problem.

Using an Array would also allow you to

select everything via []

select a specific entry [1]

select several sepcific entries (which other approaches can't easyil do) [0,1]

That sounds like the cleanest option so far imho.

TakahikoKawasaki · 2024-02-23T17:24:54Z

As a compromise for the existing implementations, my suggestion would be fixing the text that becomes ID-1 with nested approach. and than after ID-1, incorporating the array approach defined in this PR.

That would mean two breaking changes.

Is it suggested to incorporate a temporary solution (the nested approach) into ID1, even though it may be replaced in the future with another solution (the "array" approach)? Is this a proposal to improve the specification, or a suggestion to ease the workload of developers working on ID1 in a specific company? If the answer is the latter, it is a significant concern for the community.

Sakurann · 2024-02-23T18:54:22Z

It's a suggestion to improve interoperability among the companies that have already implemented the current specification text, of which there are quite a few, and which are part of the community, while improving the specification.

bc-pi

There's a lot of activity on this right now but I'm anyway leaving a review/comment to express (continued) support for the general concept and direction the PR.

Sakurann · 2024-02-27T14:25:13Z

I think we should have the discussion about what we want to prioritize: having a cleanest solution possible, or having a solution that builds up on what has already been implemented.

awoie

Generally supportive of the direction of this draft.

Sakurann · 2024-02-27T15:51:52Z

@awoie Mattr has implementation of VCI in production. You are preferring a larger breaking change from what you have?

tlodderstedt · 2024-02-27T16:25:22Z

I think the PR would bring a significant improvement to the VCI spec. However, I would like to point that it is a significant breaking change. Merging this PR now will make existing implementations incompatible and require us to restart the ID1 review process.

I would like to understand what existing VCI implementers think and whether they support the change being merged now.

The alternative would be to fix the most important issues brought up in #266 by allowing the key words mandatory, value_type, and display to be differentiated from ordinary claim names by adding a prefix _, for example. The text could also be changed to allow for the key words, at least display, in objects.

That might not be as nice and clean as the change proposed in this PR, but it could be specified in a backward compatible manner and would allow us to continue the ID process.

paulbastian · 2024-02-27T18:07:10Z

How about not replacing the claims object but instead having a different parameter name for the new object. That would allow for better transition as Issuers could support both old and new format.
We could leave a statement that old format will be deprecate with ID-2?
This would give Wallet Providers some months to support the new structure and roll out updates.

selfissued

It doesn't seem that the proposed solution solves the whole problem. I'd suggest not trying to apply it before Implementer's Draft one is approved.

After that, we can look at a wholistic solution.

As discussed on yesterday's working group call: #266 (comment) As it seems likely that #276 will not make it into implementer's draft 1, we instead add warnings about the known limitations of the current data structure so that implementer's are aware. Note that I have not applied this to the mdoc profile section, as that sections seems not to allow nested objects in the metadata.

sloops77 · 2024-05-07T00:11:38Z

openid-4-verifiable-credential-issuance-1_0.md

+    wallet did not request the inclusion of the claim, and/or if the Credential
+    Issuer chose to not include the claim. If the `mandatory` parameter is
+    omitted, the default value is `false`.
+  * `value_type`: OPTIONAL. String value determining the type of value of the


I feel that value_type needs more description.
Is the default string?
The following value_types that are needed by our wallets are

iso8601_date

iso8601_time

iso8601_datetime

iso8601_duration

uri

image/* where the credential has a generic image type like the HTTP accepts header

sloops77 · 2024-05-07T00:12:23Z

openid-4-verifiable-credential-issuance-1_0.md

+    properties of a certain claim in the Credential for a certain language.
+    Below is a non-exhaustive list of valid parameters that MAY be included:
+     * `name`: OPTIONAL. String value of a display name for the claim.
+     * `locale`: OPTIONAL. String value that identifies language of this object


Open badge v3 credentials are used extensively throughout the education sector in the US. OBV3 supports an "identity" object that contains variable data. For example

{ "identityHash": "jane@example.com", "identityType": "email" }

but the same structure can also hold a name

{ "identityHash": "Jane Foobar", "identityType": "name" }

Something like the below would support it, but it requires conditional logic

[{ "path": ["identifier", "identityHash"], "display": [{ "name": "Name", "path": ["identifier", "identityType"], "condition": "= 'name'" }, { "name": "Email", "path": ["identifier", "identityType"], "condition": "= 'emailAddress'" }] }]

where condition must require [< <= = != > >=] <literal>.
It benefit being that it can be combined with the locales

Does this mean you have polymorphic claims?

@paulbastian yes, and it's not just me. https://1edtech.github.io/openbadges-specification/ob_v3p0.html#identityobject

danielfett added 6 commits February 20, 2024 19:49

Define claims display description and claims path query

e47e3cf

Fix claims parameter descriptions

2c25819

Fix reference

bf614fc

Note on order of elements

ae77d25

Attempt to fix rendering

5bb289f

Adapt examples

46f739f

danielfett marked this pull request as ready for review February 21, 2024 07:44

danielfett requested review from Sakurann and tlodderstedt February 21, 2024 07:44

mickrau requested changes Feb 21, 2024

View reviewed changes

Sakurann requested review from jogu, selfissued, c2bo, tplooker, awoie, bc-pi, ve7jtb and pmhsfelix February 22, 2024 16:02

paulbastian requested changes Feb 22, 2024

View reviewed changes

pmhsfelix reviewed Feb 22, 2024

View reviewed changes

Sakurann mentioned this pull request Feb 22, 2024

Opportunities to improve the credential query/request syntax openid/OpenID4VP#112

Closed

peppelinux requested changes Feb 22, 2024

View reviewed changes

Sakurann requested changes Feb 22, 2024

View reviewed changes

peppelinux reviewed Feb 23, 2024

View reviewed changes

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

peppelinux requested changes Feb 23, 2024

View reviewed changes

TakahikoKawasaki mentioned this pull request Feb 23, 2024

Wallet can't always identity whether key proof is required #175

Open

Update openid-4-verifiable-credential-issuance-1_0.md

ba188d7

Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>

cryptphil reviewed Feb 23, 2024

View reviewed changes

awoie requested changes Feb 23, 2024

View reviewed changes

Sakurann mentioned this pull request Feb 23, 2024

credentials_supportedcredential object with different formats #268

Closed

bc-pi reviewed Feb 23, 2024

View reviewed changes

awoie self-requested a review February 27, 2024 14:28

awoie reviewed Feb 27, 2024

View reviewed changes

selfissued requested changes Feb 27, 2024

View reviewed changes

jogu mentioned this pull request Feb 28, 2024

Add a note about the known limitations of the credential claim metadata #280

Closed

Sakurann mentioned this pull request Mar 1, 2024

JSONPath/Pointer changes for 2.1 decentralized-identity/presentation-exchange#456

Open

sloops77 reviewed May 7, 2024

View reviewed changes

paulbastian mentioned this pull request May 7, 2024

Credential Issuer Metadata - nested objects & display properties #315

Closed

Sakurann added the do-not-merge label May 7, 2024

	* `claims`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).
	* `claims`: OPTIONAL. An array of claims path queries as defined in (#claims-path-query). The parameter is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued containing exactly those claim(s).

	* `credentialSubject`: OPTIONAL. An array of claims description objects as defined in (#claims-description), excluding the `display` and `value_type` parameters. The `mandatory` parameter here is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued with those claim(s).
	* `credentialSubject`: OPTIONAL. An array of claims path queries as defined in (#claims-path-query). The parameter is used by the Wallet to indicate to the Issuer that it only accepts Credential(s) issued containing exactly those claim(s).

	* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a certain `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims description objects as defined in (#claims-description). The namespace applies to the claims described in the array of claims description objects.
	* `claims`: OPTIONAL. Object containing a list of name/value pairs, where the name is a `namespace` as defined in [@!ISO.18013-5] (or any profile of it), and the value is an array of claims description objects as defined in (#claims-description). The namespace applies to the claims described in the array of claims description objects.

		@@ -2236,6 +2215,118 @@ The following is a non-normative example of a Credential Request with Credential

		The value of the `credential` claim in the Credential Response MUST be a string that is an SD-JWT VC. Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

		# Claims Description {#claims-description}

		@@ -1987,13 +1989,7 @@ The following additional Credential Issuer metadata parameters are defined for t

		* `credential_definition`: REQUIRED. Object containing the detailed description of the Credential type. It consists of at least the following two parameters:

Define claims display description and claims path query #276

Are you sure you want to change the base?

Define claims display description and claims path query #276

Conversation

danielfett commented Feb 20, 2024 • edited Loading

mickrau left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi Feb 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulbastian Feb 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sakurann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielfett commented Feb 23, 2024

Choose a reason for hiding this comment

awoie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi Feb 23, 2024 • edited Loading

Choose a reason for hiding this comment

bc-pi Feb 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

c2bo Feb 24, 2024 • edited Loading

Choose a reason for hiding this comment

TakahikoKawasaki commented Feb 23, 2024

Sakurann commented Feb 23, 2024 • edited Loading

bc-pi left a comment • edited Loading

Choose a reason for hiding this comment

Sakurann commented Feb 27, 2024

awoie left a comment

Choose a reason for hiding this comment

Sakurann commented Feb 27, 2024

tlodderstedt commented Feb 27, 2024

paulbastian commented Feb 27, 2024 • edited Loading

selfissued left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielfett commented Feb 20, 2024 •

edited

Loading

bc-pi Feb 22, 2024 •

edited

Loading

paulbastian Feb 22, 2024 •

edited

Loading

bc-pi Feb 23, 2024 •

edited

Loading

bc-pi Feb 23, 2024 •

edited

Loading

c2bo Feb 24, 2024 •

edited

Loading

Sakurann commented Feb 23, 2024 •

edited

Loading

bc-pi left a comment •

edited

Loading

paulbastian commented Feb 27, 2024 •

edited

Loading