jiebi/CodeConvo huggingface dataset:
Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above.
(we can discuss whether URI scheme is a good solution in general but this is a separate topic and whether we should not limit to be a URI)
NAME at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain
I think there is nothing wrong with: using an HTTPS URI for the value hosting a well-known for that URI including a header with a URI SAN entry that matches the iss value adding to the header In that case, using the to indicate whether well-known is supported or not would not work because like NAME mentioned, apparently OpenID federation uses as well and I believe in that case, well-known is not required. Please correct me if I'm wrong. NAME Can you explain how OpenID federation resolves the ?
To be clear, the above is valid. To be clear, the above just means that using to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a .
NAME sure, thank you for asking imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor. the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies. once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on). using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata
the resolution of the kid is interesting we may have a discovery, using well known endpoints we may have a static trust chain, provided like a x.509 certificate chain
NAME To be even more clear, they might not host a SD-JWT VC Issuer Metadata well-known endpoint but they might host an OpenID Federation well-known endpoint.
Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.
URL
I was wondering if there might be a mistake in the encoding of the address given in example 4: The documentation says: I assume this should be ? It looks like the claims where added to the list on error and there is a missing hash. I would expect to see some additional disclosure elements for postal_code, ... (each with a nonce) similar to instead.
Thanks for catching that! There is definitely a mistake in Example 4a. But it looks like the problem has to do with decoy digests in that example. The decoys listed at URL got pulled from the wrong place and so don't match up with the other example content, which includes the address claim Disclosure you've pointed. That all makes parts of that Example 4a problematic and hard to follow. I think it'd be best addressed by not including decoys in Example 4a. This is related: URL FWIW
PR aims to fix this. A preview from that PR of that example: URL and specifically the Disclosure for address: URL
Thanks for the quick response! That looks much better. I was expecting the address to be passed in a way that allows the selective disclosure of single items (e.g., only the post code). Maybe you can add an additional comment which of the three options in 5.7 every example uses (here 5.7.1). To me, having three options in 5.7 makes it unnecessarily complicated. and 5.7.3 are basically the same when you would allow having non-selectively disclosable items in this as well. If that would be the case, this could probably also handle all cases 5.7.2 would be used for.
Thanks for reporting this and NAME thanks for the quick fix! NAME The options in 5.7 are meant to show what is possible with SD-JWT and are not meant to restrict or define how can be encoded. It is up to the issuer to decide for each claim whether it should be SD or not. Options 1-3 just show some of the possible results. I'm not sure I'm following what you mean by "having non-selectively disclosable items in this as well". Could you give an example?
I created this PR to ensure that our wording around the options is clear in that the options are non-normative and not exhaustive: URL
I was wondering, if 5.7.1 would allow to have non-selectively disclosable items in the address claim: This single definition could then cover all use cases of 5.7.1,5.7.2, and 5.7.3. But i see what you are up to (thanks for ). You do want to leave a maximum flexibility. However, i am a bit concerned of "creative" uses of what is technically possible and how to make sure to be able to parse/process all possible combinations in the openid4vp context.
Yes, this mixture is possible within the current specification. With the algorithm defined in Section 6.3 there is no need (for the Holder) to be aware of all possible combinations. (In other words, such assumptions should never be hard coded.) It is just the Issuer that has to make a decision on which pattern to use.
Sure, this should never be hard coded. However you need e.g., to come up with a user friendly way of displaying that kind of information in a wallet context. It is a challenge to find an intuitive/understandable way to inform the user which information will or can be disclosed and so on. But this is becoming way to off-topic ;) Thanks for your quick response!
URL merged
I don't know why but I think we should have more examples, but not going to go against these changes.
Added privacy considerations section from SD-JWT which provides a good foundation. ,
Currently, is not one of the selectively disclosable claims. This might be ok but it might have some privacy implications if a VC has multiple types. Let's assume the following: A VC with the types: driver's-license, age-over-18. If the holder discloses only the age, then based on the current specification, the verifier would also know that the age was disclosed from a DL which is probably unnecessary context info since all the verifier needs is to trust the issuer of the VC. Note, the issuer itself might also leak some contextual info as well, so the issue might not need to be mitigated or it might not be entirely possible anyways. Should we make selectively disclosable per array entry? Is this even supported by SD-JWT?
Closing this issue since SD-JWT doesn't support selectively disclosing array elements.
We might want to add something to privacy considerations about that.
FYI: There is a discussion about Selective Disclosure for array elements. URL
suggest to close as the type is a simple string now
NAME raised an issue with me that "if the type is always disclosed, what is the point of selective disclosure because the verifier will know what claims are in the credential". I think we should consider making type selectively disclosable.
I agree with Peter and I'm in favor of sd for type
What is the value of a VC without type information? Or let me put it the other way around. If the Verifier is supposed to be able to process a VC without knowing the type (which also means it can request the VC presentation without specifying the type), why do we need the type at all?
I was wondering about that point as well - what is revealed information worth without information about credential type (and corresponding trust framework).
It becomes valuable if all the verifier wants to know is a specific claim, e.g., , and trusts an issuer which could issue other credential types as well. The credential type can also make a difference, e.g., if somebody wants to know whether somebody has a driver's license but is not interested in the details.
My current assumption is that is the primary selection criteria for credentials in a presentation request (as identifier for a pre-defined bundle of claims associated with certain policies for enrollment and issuance). Based on that assumption, the Verifier always knows the type.
So what would be the scenario to request a VC without knowing its type?
Having the type disclosable does not mean the user never shares it. If a verifier requests the type then the user can disclose it, no? The issues with both the and the is that they reveal what claims the user has, which is more than what is strictly required for a service. The privacy requirements from the Parliament, Council, and the Commission are strict. However, I cannot think of a scenario to justify type being disclosable. Arguments for: As NAME mentions, the verifier may require only a particular claim, e.g., age over 18, and should reasonable accept these from any trusted issuer without having to know what exact attestation type it came from. Some issuers may have multiple types that all contain the same attribute. And there are strong demands that the user should reveal only what is required for the service and absolutely nothing else (to the point where I am actively having to fight against people who want to put ZKP everywhere). Not revealing claim values is great; also hiding what claims you have is more privacy preserving. Arguments against: Beside from those already mentioned, you could question the privacy benefits. As long as the individual Issuer's signature is included, it is likely not that hard to guess what the particular attestation may contain, particularly if the Issuer only issues few attestations. In conclusion, given how there are no technical challenges to making type disclosable, and how the Verifier may just request a type and refuse to process a presented claim without type disclosed, I would argue for that the type MAY be disclosed.
The field is always disclosed, hence not revealing the only offers privacy if the same issuer with the same key offers multiple VCs that share the same claim name that is being requested. It seems like an unrealistic scenario that this is a privacy benefit. It seems to me the usecase would be merely a fillout help, where the verifier does not care about the origin of claims and handles those as self-attested
Let's create a PR and see how the spec will change and continue the discussion there.
Currently, the spec gives the following function: Given that, I don't think it can be selectively disclosed. We should close this issue.
The best and easiest plan is to discard, but we know that throwing out perfectly good packets can have bad effects on performance. It sends a bad signal to a congestion controller for instance. So we need to say either discard, or ensure that the data is properly attributed and consistently processed.
I think you covered it all this way. +1.
The conclusion in the draft is that early data is relatively "safe" (for some definition of the term, see the draft for details) if the handshake is complete. Early data in a transport that provides ordered delivery will always arrive before the handshake completes. But this is not the case in QUIC, or anything like DTLS. We should offer some advice for these situations. From martinthomson/http-replay
But can this really happen ? I mean, my understanding is that the handshake happens in response to a Hello message which also conveys early data. Can we have early data outside of a hello message, or may we receive a handshake response before a hello message ?
With reordering of packets in QUIC, you can get a packet that was sent before the handshake completes after the handshake completes. The order of sending might be "ClientHello, 0-RTT1, 0-RTT2, Client Finished", but the server can get "ClientHello, 0-RTT2, Client Finished, 0-RTT1". Early data is sent in separate packets (this is a hard rule right now, but we might change the format so that the packets can be sent together in future). This is unlike TCP fast open where you only get to send the "early data" in the SYN segment. You can send an awful lot of early data if you want.
OK thanks for the explanation. I tend to think that such behaviours are out of the current scope of the draft but will fall into it as QUIC progresses. Maybe all of this can be summarized (for now) as "In case a TLS implementation supports receiving early data after the handshake completes, such early data has to be silently discarded". That covers this case for QUIC and any possible TLS implementation specificity or even bug.
I think that we might add "... discarded unless the data can be unambiguously identified as being early data" or something like that.
After all, it's not replayed data if the handshake completes, so I don't want to prohibit its use. The main problem is that it's hard to properly identify and handle. FWIW, we debated this for our DTLS 1.3 implementation and chose to discard. That is the easiest answer.
I'd still be tempted to simply discard for now, just to avoid the problems of confusing the client with an out-of-order handshake that may make it think the "late" early data were lost while in the end they are considered. I'd rather avoid a client sending a request again as regular data and seeing the server concatenate it with the late arrived early data for example. I really think it's something we can improve later as the out-of-order use cases become more obvious. It would also offer us a safety belt allowing more fancy stuff in QUIC, otherwise we could end up saying "nah don't do this or that, it could cause trouble with early data". The rule might then be relaxed. It will not affect TCP-based implementations anyway.
NAME Whats' failing on the build here?
breaks the build All RFC references are resolved interally and linked
There are possible applications of this draft that go beyond just verifiable credentials, hence we do not want to use that term in this draft IMO. "Token" is already a term broadly used in this space e.g CWT and JWT both use it, "subject" was used in this context because it is also a term used heavily w.r.t tokens, feel free to suggest alternative terminology but at this point I think subject token is the best I've heard suggested.
can we simply use JWT/CWT instead of creating any kind of abstraction term like ? One person i asked for feedback associated with a token used to communicate a subject of an email.
or, bottomline, please stick to . is very confusing.
I'm with Tobias on this and prefer introducing a new term here. Otherwise things get really weird because the status list is also a JWT/CWT and a token. We need something that clearly separated the status list token and the other token. I think subject token is the best we have. Also subject is leaving towards what we have as credentialSubject in the VC world, so the term subject is kind of established in this context
I am really strongly against "Subject Token". Not only because it is not intuitive (I have been asking various people in this space and no one would associate what it trying to be conveyed), but we should not be introducing a new term in this already confusing ecosystem. Moreover, this status list mechanism can be used with a JWT/CWT that does not necessarily contain a subject (like SD-JWT-VC), so using a term subject because it is widely used is not a sufficient reason. Keep referring to it as a token, because this draft should not be opinionated about what is in the JWT/CWT whose status is being expressed should be fine, if a "status list JWT/CWT" is always referred as such. there are multiple occurrences where "status list JWT" is referred to simply as a JWT which should be fixed IMO.
We need clear terminology for: the status list token (i think this one fits pretty well) the credential / token that is bound to the status list I do believe only calling it token will cause confusion with the status list token.
We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Updated firmware and Software integrator use case to the same format as the ones above.
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
based on .
This PR would address both and
also would
based on some twitter feedback URL
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain). End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.