Editorials, defined terms #85
Conversation
Co-authored-by: Torsten Lodderstedt <torsten@lodderstedt.net>
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md
Outdated
Show resolved
Hide resolved
openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md
Outdated
Show resolved
Hide resolved
peppelinux
changed the title
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
selfissued
left a comment
selfissued
left a comment
There was a problem hiding this comment.
Approved with a change suggestion.
| # Terminology | ||
|
|
||
| This specification uses the terms "Holder", "Issuer", "Verifier", "Wallet", and "Verifiable Credential" as defined in @!OIDF.OID4VCI] and [@!OIDF.OID4VP]. | ||
| This specification uses the terms "Holder", "Issuer", "Verifier", "Wallet", "Wallet Attestation", "Credential Type" and "Verifiable Credential" as defined in @!OIDF.OID4VCI] and [@!OIDF.OID4VP]. |
There was a problem hiding this comment.
I think we should split this into terminology defined by specific specs ( termy x,y,z in VCI and a,b,c in VP) similar to how it is done in VCI and VP currently.
There was a problem hiding this comment.
@c2bo: Not sure what you are asking for here. I did a side-by-side comparison of the terms defined in the Terminology sections of the VP and VCI specs: there is a lot of overlap, but not 100%. Perhaps you are saying that a reference to clause 2 is needed in the references in this text? In any case, I think the first part of this this sentence should read "This specification uses terms such as..."
| - to sign and validate the Holder's signature on the Verifiable Presentation | ||
| - to sign and validate the Verifier's signature on the Presentation Request | ||
|
|
||
| Issuers, Holders, and Verifiers MUST support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [@!RFC7518] for the creation and the verification of the above signatures. |
There was a problem hiding this comment.
| Issuers, Holders, and Verifiers MUST support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [@!RFC7518] for the creation and the verification of the above signatures. | |
| Issuers, Holders, and Verifiers MUST at least support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [@!RFC7518] for the creation and the verification of the above signatures. |
There was a problem hiding this comment.
- the intent is to allow using non P-256 algs. credential does not have to be signed using P-256. if credentials signed using other algs wants to use HAIP, they need to define
- this intends to say P256 is a fall back and is minimum mandatory to implement
- there might be secure areas that might have to add P256 compliance just to be HAIP compliant? which might be limiting
- these requirements might make sense for issuance but not presentation?
There was a problem hiding this comment.
- for the key for issuer signed data, Wallet has to accept P256 for SD-JWT/IssuerSigned (issuer communicates what it supports in the issuer metadata, can be P384).for the key for holder binding, issuer has to accept P256 for KB JWT/DeviceSigned;
- for presentation, for RP, mandate P256 to use it to validate. no requirement for the wallet has the credential, it already has it.
There was a problem hiding this comment.
How does the text contradict your statements?
There was a problem hiding this comment.
@Sakurann from my perspective, the MUST and MUST at least requirements produce the same expected result. Implementers must support P256 regardless of whether the requirement is stated as MUST or MUST at least.
| * There are mechanisms in place for the verifiers and issuers to discover each other’s capability | ||
| * The Issuers and Verifiers cannot pre-discover Wallet’s capability | ||
| * The Issuer is talking to the Wallet supporting the features defined in this profile (via Wallet invocation mechanism) | ||
| * There are mechanisms in place for the Verifiers and Issuers to discover each other’s capability |
There was a problem hiding this comment.
what does this mean? Why need verifiers need to discover issuer capabilities and vice versa?
| * The issuers and verifiers cannot pre-discover Wallet’s capability | ||
| * The issuer is talking to the Wallet supporting the features defined in this profile (via Wallet invocation mechanism) | ||
| * There are mechanisms in place for the verifiers and issuers to discover each other’s capability | ||
| * The Issuers and Verifiers cannot pre-discover Wallet’s capability |
There was a problem hiding this comment.
I think this section needs to be reworked. It does not match the situation with DC API in place.
| - to sign and validate the Holder's signature on the Verifiable Presentation | ||
| - to sign and validate the Verifier's signature on the Presentation Request | ||
|
|
||
| Issuers, Holders, and Verifiers MUST support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [@!RFC7518] for the creation and the verification of the above signatures. |
There was a problem hiding this comment.
How does the text contradict your statements?
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
|
3 approvals, discussed briefly on today's WG and open for pretty long - Giuseppe has I believe addressed all comments apart from the one Torsten opened an issue for - if we missed any please feel free to open a new issue, but let's merge this and get the bulk of the changes in and continue to iterate on improving the spec. |
7 participants
This PR Closes #69