jiebi/CodeConvo huggingface dataset:
In Bob's TSVART review, he notes in Tb that the mention the H2 DoS attack in Security seems useful and we should probably expand on it. The mentions of H2 have been whittled down as 7540bis progresses and the reference to CVE-2019-9513 in the security section now seems misplaced. It's cleaner to just remove it so that the section focuses on considerations for using this document. P.S I think this means that MT was right ;)
Addressed issue NAME NAME
Feedback from Dean Saxe during WGLC Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. URL
Adressed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report. The current definition likely needs to expand a bit to account for: What are the versions of a specific artifact What are all the statements for a version of an artifact What is the latest statement for a specific of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.
This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.
NAME I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it? Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.
A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
URL and I don't know why my response isn't on the mail archive yet but here's a copy: !
oh hey that's fun:
sadness addressed in 9b7ad2d010e0f49e3dd8b5833c59fe4642e2892b (on the surface anyway)
isn't part of this duplicate of ?
Yeah, I did it here first just to fix things. Then decided fixing the build process should be decoupled from addressing one more of Mike's previous review comments.
Now overcome by events. I'm going to resurrect exactly one of my previous review comments that was not addressed. The original comment was: Issuance: There are many places from here on where the label "SHA-256 Hash" is used, for instance "SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4". Change all of these to "Base64url-Encoded SHA-256 Hash" for correctness. Brian responded "The current wording might not be as descriptive as you'd like but it is correct." I'll water down my request if you're not willing to change all the occurrences to "Base64url-Encoded SHA-256 Hash" to then please at least add a textual caveat before the first such occurrence along the lines of: In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". As I said in my initial review, I look forward to this specification being published as an RFC. Best wishes, -- Mike From: Rifaat Shekh-Yusef Sent: Tuesday, September 3, 2024 3:39 AM To: oauth Subject: [OAUTH-WG] WGLC for SD-JWT All, As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by Sep 17th. Regards, Rifaat & Hannes
This PR: adds relationship to other docs section - preview here: URL
One little nit on the text but otherwise looks okay (after the couple iterations by NAME and NAME thanks for those).
NAME pls approve if you are happy with the latest language, then we will merge the PR.
Data model in this document resembles to the ID Token data model as defined in OIDC (with the addition of cnf). On the other hand, the data model is trying to follow the W3C VC data model. What is the benefit of this data model over the W3C VC data model (except that the claim names are different and iss can be a URI, and not an object and that JSON-LD is not supported by the data model, which basically excludes some significant use cases such as Europass that are leveraging JSON-LD for internationalization, for example)?
It is simple, leverages all predefined JWT claims (including eKYC), and can be used by people familiar with the JWT model to also implement VCs - with SD-JWT also with selective disclosure capabilities. So it clearly gives an easy migration path from the federated to the issuer-holder-verifier model. We tested the idea with some projects and communities and it seems a lot of implementers like that. Regarding Europass and other JSON-LD-based credential schemes. There could be another spec defining how SD-JWT could be used with JSON-LD.
eKCY defines its own data model same as for ID Token. eKYC can be easily mapped to VCs. The only real difference is the name of the metadata claims (iss vs issuer, iat vs validFrom, etc.) But SD-JWT can be used with W3C VCs (bot as SD-JWT is and W3C VCs as they are).
eKYC defines an extension that can be used in any JWTish environment. Doesn't work with W3C VCs due to the split between subject related data (credentialSubject) and metadata (evidence). Ask Mark Haine. not sure what you mean. can you please explain.
We did some mapping in the past (it was some time ago, and I don't remember how far we got): Evidence in VCs is optional and the model and use of evidence for eKYC doesn't make a lot of sense since eKYC already defines the full data model.
eKYC can be nicely modelled within the credential subject. There were discussions around re-using the model of eKYC for expressing different levels of verifications. Essentially it was something like: verifiable-attestation-URL is the VC data model e-kyc-verifiedclaims-2022-URL - is the JSON schema of the eKYC
Just had a chat with Alen about typing and want to share the conclusion. We think typing happens on the following levels: Payload of a (HTTPS) response - here, a processor needs to know how to process the object (blob). So on this level, the media types or should be used. JOSE header - on that level, the determines how the payload of the JWS shall be processed. fits on that level. It governs the format (SD-JWT, which implies JSON) and what claims MUST be present (e.g. and ). Those claims are related to security of and trust in the credential. They are not related to the further domain specific structure of the credential. In SD-JWT VC, we use the claim to determine the structure/schema beyond the basic structure determined by the JOSE header. A university credential, for example, will have different rules for the schema of the payload than a drivers license. NAME NAME NAME NAME NAME NAME NAME Please let us know, whether we are on the same page. If so, it might be beneficial to add some text along those lines to the draft.
on point 1, I think that is ruled by the underlying protocol - OID4VP/OID4VP define those ( and ) I do not think sd-jwt vc draft should say anything about that. on points 2 and 3, i think i agree
to answer the original question raised in the issue, the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like will not be conformant. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it.
How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. VCDM itself is silent about how to sign/process the I would absolutely not equate ID Token data model to a VC data model. VC data model needs one step to get to the ID Token usability which is defining how the concepts defined in VCDM are mapped to the JWT claims and how to sign/process that JWT claimset, which is what this sd-jwt vc draft attempts to do.
NAME I think we need to at least scope the media type definition in the spec as those definitions are related to the only, not request payload.
why it can't be left to the protocol? why it can't be ? just for example: URL
NAME the way VCDM 2.0 is going, it requires data model to be JSON-LD and processed according to JSON-LD rules, so things like NAME is in the payload, we put it to be conformant, but are not processing it will not be conformant. Please check the discussion in URL since the conclusion is different. NAME What do you understand under LD processing? (LD processing with VCs is used only by: data integrity proofs, selective disclosure that's been just defined, internationalisation, identity matching, some advanced querying) Since JWS is not using any of that, JWS protection mechanism is not affected by the -LD part. However, it enable use cases, that want to use the -LD (e.g., ELM v3) for internationalisation etc., to use it. When VCs are secured with JWS, LD processing is not performed. It MAY be performed, if use case requires it, in the post-processing (after the validation) or rendering phase. the value of VCDM IMO is defining the concept of a credential in a three party model: issued credential must contain the issuer, the subject, claims about the subject, metadata about the issuance of that credential (iat, exp, etc.) and optionally a cryptographic key. that's it. How to map it to the JWT claims is not the expertise of w3c vc wg nor is well-defined in the documents produced by that group. That's perfectly fine. W3C VCDM is focusing on the VCDM data model.
Note that the current VCDM v2.0, without any JWT claim, is a valid JWT. VCDM itself is silent about how to sign/process the data model I think this is a good approach of the specification, since it defines a data model. Securing mechanism should be defined by specifications like JAdES which defines a profile for JSON-based AdES.
Reason is simple and it is following the basic architecture/design principles. Signature (e.g., JWS) defines the serialisation and with it the resulting type. JWS specification cannot and should not know anything about the protocol that will use it. When a protocol defines a profile or a set of supported elements, the protocol needs to ensure that the media type that's defined consistent with the elements it selected.
NAME Perhaps I did not explain well. This is the media type definition from the spec. It does not describe the context where the media type shall be used. So people might think this is a media type that should be used as content type of an HTTP response. I think we agree this is not the case. All I'm suggesting is to document the intended use in the JOSE header (and as format identifier in credential exchange protocols). Would you agree?
I don't agree that it is a good idea to take VCDM claims and use all of those to secure JWTs, because there are existing claims from JWT claims registry and existing implementations depend on those
NAME thank you for your feedback and I fully understand your concern. We need to put things into a context: most of those cases operate within closed systems where everything is well defined - data models, verification rules, etc. Within this context, I fully agree with you. Securing JSON-LD can be done today by JAdES (pure JWS, no JWT). I believe it is worth to read and reflect on it URL From my experience, the NAME is really processed (in most cases) outside of the verification scope/process. There are signatures that rely on the context, however, that's not relevant for JWS and this discussion. (In a brute-force scenario context can be embedded/inline and problem solved - size is the price to pay - not in the scope of this discussion) Since JWT specifies that all claims are optional, libraries should be able to process JWT tokens without any JWT claims (I know how it sounds).
From experience, JWS/JWT libraries verify the signature, other verifications are performed manually. People could also argue that VCs are used. This direction won't lead to a solution. ID Token and eKYC define rules for the JWT claims when they are secured with JWS. I believe there are many other use cases that define profiles, rules, etc. In an open multi-use case system, there are additional challenges and we had a good discussion with Torsten on the topic where we identified several points that should be considered. It is worth reflecting on the designs of JWS JAdES linked data proofs VCDM v2 on their data model and serialisation. Back to my question: What is the real benefit of this data model over the W3C VC data model by looking at the situation objectively? (I'm also trying to find an answer to the question) With Torsten we had a very fruitful discussion. We need to reflect on several elements. Have a nice weekend!
NAME , I missed one point. Can you please elaborate on "take VCDM to secure JWT"? If my understanding is correct (sometimes is, sometimes isn't), it is JWS the one secures the payload (and it can be any JSON). JWT claims define contextual information: who, validity, about who, for whom. We should reflect on sigTst from JAdES. I'm personally not proposing to use VCDM to protect a JWT. VCDM and JWT are both protected by JWS.
As an example, iss and cnf are registered claim names for JWTs that are used to secure the VC. Existing RFCs are using those. Therefore it doesn't make sense to overwrite those by the w3c data model in my opinion
Thank you NAME I understand your view. If VC claims were registered, what would be the benefit of the data model over VCDM? Since I’m involved in projects that use VCDM (in JSON and JSON-LD) and also JWT I would really like to understand the objective benefits od the data model.
To resolve this issue, we will add a section on relationship to other documents and include a chapter on "VCDM".
This issue is ready for a PR.
Approved with a minor proposed improvment.
rfc7141 partially updates rfc5033; include relevant sections in the -bis document
7141 does not mention 5033, so can you be more specific?
Oct 12: Pinged NAME to follow up
IIRC, it was due to rfc7141 updating rfc2914; rfc2914 is mentioned and referenced at numerous points throughout the 5033 document. 5033bis should heed the advice from 7141 around marking probabiliy taking into consideration packet sizes rather than only the packets themselves. At least this train of thought is the most likely one, which was had in my mind at the time.
Editors: we suspect that this question is orthogonal to the purpose of this document; will look more carefully at the reference.
It turns out that 7141 does have recommendations on response to congestion signals from the network, not just AQM recommendations (See Sec 2.3 and 2.4 for a good summary).
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.
. By replacing "sender" with "client", we make the urgency and incremental section more consistent with how they discuss these concepts.
Paraphrasing NAME feedback, in S 4.1 we say we might consider clearer statements about the actors are i.e. who sends this parameter, and who actions it.
For clarity, it's mainly the term "sender" in "sender's recommendations" that I find unclear here, since the server can also "send" Priority information, where it doesn't always reflect the server's "recommendation" when doing so (e.g., sometimes it's just echo'ing the client's value).
We don't really need to hammer home the "recommendation" concept, that's explained elsewhere in the document. I'll propose an editorial change to this text to focus on the thing we care about
CC NAME comment syntax: URL "Handling Ballot Positions": URL Why is the value defined as a String that can be comma-separated as opposed to a List (of Strings)? Up to you, but feel free to reference RFC 3493 section 6.1 for getaddrinfo and discussion of the AI_CANONNAME flag. "might not available" -> "might not be available"
The nit was fixed with
For the list-of-strings, parameters themselves can only contain bare items, not inner lists. URL
Add some text to indicate that proponents don't need a complete report on all the criteria before coming to IETF. They can arrive having thought about these problems a little and have a willingness to do the work implied in this draft.
We need to be nice, but not too nice. This phrase is targeting folks like researchers or PhD candidates. They should be aware that this topic is not going to be a walk in the park. But showing why the problem is hard could also be an encouragement -- you don't get a PhD for solving again a problem that 100s have already solved...
NAME PTAL
Since the use of COSE is mandatory, shouldn't this be MUST? Originally posted by NAME in URL
It would seem more appropriate to just say , rather than introduce the notion of a "standard COSE implementation". The latter would seem to involve a need to have a certification program for COSE implementations or something unnecessarily involved like that. I don't follow the implications of this. Can it be spelled out some more? I'll also note LGTM!
(this text is present in RFC 7233 as well) "A valid entity-tag can be distinguished from a valid HTTP-date by examining the first two characters for a DQUOTE." Hm, no. If we want to properly handle weak etags, we either need to inspect three characters (actually position 0 and 2) for DQUOTE, or check pos 0 for DQUOTE or pos 1 for "/". If we're not interested in weak etags, checking the first character is sufficient.