We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.


There was a feedback from Victor on making track operation string enumeration to enhance readability. It feels like a fine suggestion


Consensus for merging at IETF meeting.
Per the discussion at URL, it would be useful that if the namespace were absent, that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability.
I know there has been lots of debate on this but it seems reasonable.


I suggest creating an IANA registry for catalog fields with values auto-populated from Section 3.2.
What is the point of shifting the catalog fields definitions to IANA? IANA is useful for ensuring global uniqueness. If a single specification defines the catalog format, then that spec if a much more efficient and natural place to define the fields used by that format.
If we end up needing new fields (which we certainly will), we don't need a revised RFC. The fields table can be amended/expanded in a number of ways.


by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.


Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:


Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged


This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers


NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call


As discussed with NAME and NAME because the proof is scoped under , when , and is ultimately wrapped in bstr to make parsing optional, there is no need to obtain assignments for keys it uses internally. This PR is assigning values, and removing the requested assignments accordingly. Edit: I've found that it's possible to be more precise about sizes in CDDL, so I've tightened the schema a bit.
NAME if you have a minute to have a look ahead of today's meeting, that'd be wonderful :)
NAME CCF tests now automatically check some of the proofs against the schema: URL Since this is approved, can it be merged?
NAME yes :-)
lgtm! Thanks a ton.


In alignment with draft-bryce-cose-merkle-mountain-range-proofs (i.e. this I-D will request VDS reg entry "2" and mmrp will request vds reg entry "3").
2 is a good number. Thanks for cleaning out the attic


URL As promised at the meeting last week I have reviewed both: URL URL This is my review of the Birkholtz draft profile. REVIEW NOTES Overall very good, just a few comments: BIRKHOLTZ [Section 2]: “This document defines inclusion proofs for CCF ledgers. Verifiers MUST reject all other proof types” It’s unclear to me how useful this normative language is. Does it pollute the implementer’s wider implementation of cose-merkle-tree-proofs? In which case I think it’s wrong: verifiers might well verify many different transparent statements from a plurality of logs with a plurality of proof types. Of course for any given transparent statement they need to implement the proof verification correctly but I don’t see the value of this rejection statement. Privacy Considerations could do with some content (or removal if we consider that leaves and log activity are not relevant leakage of privacy info) Security Considerations could do with some content: CCF ledgers have certain trade-offs and assumptions about the environment they run in: should these be noted? Possibly a small nit, but “Historical transaction ledgers produced by Trusted Execution Environments” feels wrong to me. The ledger isn’t produced ‘by’ the TEE. It’s produced by a lump of code running in a TEE protected environment of some flavour. Or at least you have to hope it is. See comment on security considerations. [Section 7] reference to cose-merkle-tree-proofs is broken. Please fix. [Appendix A. Attic]: Casual language “Not ready to throw these texts into the trash bin yet.” … but there’s nothing else in there! Please remove. Jon


URL [ ] In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. [ ] In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” The draft looks good to me. I have two minor suggestions. In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” From: Michael Jones Date: Tuesday, July 30, 2024 at 1:53 PM To: "EMAIL" Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs _____ COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL


and have pointed out that the current registration requests are rather informal and could be improved using the templates in . All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock wrote:
Answering Mike P.’s question about IANA registrations, it is strongly preferred to have the IANA Considerations section follow the registration template and contain the exact values to be placed in the registry (with the Label of course, being TBD). An example of such IANA Considerations text is URL Please update the draft to add this content. Thanks, -- Mike From: Michael Prorock Sent: Friday, August 23, 2024 5:40 AM To: Michael Prorock Cc: Michael Jones ; cose Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-tsa-tst-header-parameter All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock > wrote: Thanks for the additional time Mike and Ivo. I support moving this along, but I would like to perform a detailed read through. I have some time set aside for this and will have comments back next week. Mike Prorock founder - URL Ivo and I reviewed the results of the WGLC and there have been no responses whatsoever – even from the authors. We are therefore extending the WGLC for another two weeks until Tuesday, August 27th. Unless multiple people support progressing the draft, we will not request publication. Please send your reviews and feedback on the draft. Thank you, -- Mike and Ivo From: Michael Jones > Sent: Tuesday, July 30, 2024 10:53 AM To: EMAIL Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL


In , Orie commented that: The answer is obviously "no", but the fact that the question was raised seems to indicate that the reference to 9338 is potentially confusing. Note that if we removed it, nothing would change, which is an incentive to drop. Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >


In CTT that can't happen unless you can predict the COSE signature, i.e., the content of the datum. Sorry, I don't understand this. You are making a similar point in which I am also failing to grok. To me, a timestamp asserts the existence of a datum at least at the point in time when the timestamp for that datum is created. I cannot fathom an attack in which pushing the existence of the datum back in time is an attack on the intended use of the datum.
In , Orie commented that: "Security considerations seem light."_ We could add prose that succinctly describes: the attacker model (i.e., a dodgy individual trying to manipulate the COSE signer's or the relying party's local clocks), and the trust model (i.e., local clocks are untrusted, and the TSA clock is trusted by both the COSE signer and its relying parties)
The only interesting attack is when the attacker moves the RP's clock in the future.
ltgm Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >


In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >


https://ietf-URL
NAME NAME please have a look
TSA is good enough


See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat


NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!


as discussed on [SCITT] SCITT threat model. I still need to discuss with Yogesh how to integrate some of his comments.
NAME : Thank you for this. I think, we should start Threat Model as a separate document to begin with. The reason been, I expect Supply Chain Security been a complex subject the number of threats and mitigation strategies will be a long document. I would prefer a pointer to the document from the master Architecture document, then! Once the document is in final shape post Community review, at that time we can make a final call, should we merge it to Main Arch. Doc or leave it separate.
Considering the scale of the addition and the fact that stand-alone terminology or threat models are a bit frowned upon, I think we should merge this PR for now. If there is a need for a separate threat model I-D we can arrive at that conclusion in the WG and with AD and chair guidance. Keeping the number of I-Ds the same during chartering is a pro and not a con, I think.


Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage


This adds temporary integer header parameter labels to have something to prototype against until the new fields are registered. I used 391 as starting offset as that's S+C+I+T+T.


Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.


Changes: Remove initial version from CCF tree alg identifier. The idea is to not be linked directly to major CCF software releases but rather version independently here. For now, there is no need to include a version number in the tree alg identifier. Remove CCF hash alg parameter as that is always implied by the signature alg. CCF signs pre-hashed data (the Merkle tree root) and doesn't hash twice.


The first change is to address the fact that the current .md renders correctly as bullet list on Github but not in other contexts such as URL


Allowing both a receipt and an array of receipts as type is ambiguous here since the receipt is an array itself and not wrapped, so distinguishing the two cases wouldn't work. Having a single type also simplifies client code.


A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM


Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100. The transparency service knows that animal products require certificates to be imported, and issues a challenge token that looks like this: iss: "https://transparency.example" aud: "https://transparency.example" iat: ${now} exp: ${now + 7 day} currenttreehead: ... (not all TS are trees) currentpolicyhash: ... (not all policies are stored in trees) entrynumber: 42 htscodes: [ 16056100 ] The holder starts registering signed statements, each is bound to the same "challenge token". The first signed statement covers a phytosanitary certificate for the sea cucumber processing facility. The regulatory requirements change. The second signed statement covers the (now required) export certificate for sea cucumbers. The transparency service would normally have rejected the second signed statement, but because of the context in the challenge token, the transparency service knows that the second signed statement is now actually required. The holder did not need to request a "new challenge token" when the regulatory changes happened, and the holder still had to prove possession of the public key bound to both certificates ( and these public keys are different ). I chose to make this context scenario about sea cucumbers, but it could easily have been about network capable hardware devices that need to comply with regulations specific to Radio Antennas and GPUs... In those cases there would be firmware certifications required, and compliance requirements might change inside the transaction window. This also solves the problem of forcing the issuer to commit to the registration policies as they exist at the time the "challenge token" is issued. The TS can reject registrations that are committing to stale policies, or accept registrations that are commiting to stale policies, because the TS will know which policies the issuer is committing to by checking the challenge token. In the case that proof of possession is not required, and there is no need to commit to policies, the challenge token can be omitted, and the registration can proceed exactly as it is specified today. OS ORIE STEELE Chief Technology Officer www.transmute.industries


Introduction: Removed excess carriage returns Problem Statement: Added new text (threats + artifacts) and illustration (threats)
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.
LGTM!


Modified the 'Scalable Determination of Trustworthiness in Multi-Stakeholder Ecosystems' use case to improve lay person understanding by reducing the number of terms introduced.
thank you! lgtm


Added a placeholder section to aggregate problem statements across use cases. Refine and complete this section as use cases stabilize.
:ship: it


Signed-off-by: Henk Birkholz
Henk, The Distributor isn’t always the signing authority. It’s true in some app stores, but beyond that the model breaks, down. Walmart doesn’t digitally sign software it sells/distributes. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Then this is going on the agenda for Monday, too. Thanks Dick
Thanks, Henk. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
From discussion with Henk I believe the use-case here is an app store-like promotion scenario. If that's true, I recommend we refer to this as the relationship between a supplier/producer and the distributor. While signing is a property of the relationship between an app creator and an app store we can increase the clarity of the use-case by describing the roles in the relationship (producer/distributor/consumer). I've made some suggestions on the PR to replace "Signing Authority" with "Distributor".


Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!


NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements


Addressing issue and
This fixes issue and issue
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.
LGTM


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.


Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!


A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.


Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!


NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.


This will help me fix this part in the writeup: Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).


Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.


Fix for
NAME PTAL
NAME PTAL
(moved to issue)
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.


Add discussion of the tx-mode SDP parameter. Fix for Rebase of
NAME PTAL
I think we need a different approach. We want to say that support for "SRST" mode is mandatory If no tx-mode parameter is present, a value of "SRST" MUST be inferred. It is up to the offering implementation whether to include SRST or omit it. implementations that do not implement the other modes should not negotiate a codec with that mode
NAME Updated the PR to include your suggestions.
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.


In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)


specifies the The low-order bits should be specifies the low-order bits Subbands to Sub-bands signalling to signaling
URL


Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.


let's publish an I-D with this PR and the one about Personal Data, then I am approving the I-D for publication


Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7


Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits


Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters


We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.


The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.


Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.


As discussed over email, this PR drafts some text to capture the requirement around refresh token binding to the client instance not just the client. The PR also addresses some broken links. Personally I'm still not convinced that the best way to do this binding is through the client attestation key, instead I think we could add a claim that identifies the client instance in the client key attestation
few suggestions


In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL


Addresses issues with language about the jti claim in the client attestation and pop jwt.
The spec states: "The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant." However the is not shown in the example in the same section.
The text says jti is required URL but the example doesn't have jti URL
Duplicate of
The Client Attestation JWT seems like a long(er) lived credential that should be reusable so the client instance doesn't have to go get a new one each time (right?). But this text for the Client Attestation JWT has 'The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant' that suggests the AS might limit them to single use. I think that sentence can just be removed. \ right: URL
Agreed, need to remove this sentence from step 7 of 4.1.1.


The "Refresh token binding" section requires "The client MUST also use the same Client Attestation." What is the intention of the requirement from the following options? The exactly same client attestation JWT. The refresh token becomes invalid after the client attestation JWT expires. Even if the attester issues a new client attestation JWT for the same client key, the new client attestation JWT would not work with the refresh token. If the requirement expects this behavior, AS implementations would simply use the hash of the client attestation JWT to judge whether the client attestation JWT presented in the refresh token flow is identical to the previous one. Any client attestation JWT for the same client key issued by the same attester. If this is the actual intention of the requirement, even after the original client attestation JWT expires, the refresh token can be used with a new client attestation JWT issued by the same attester. In this case, AS implementations would check the combination of the attester's identifier and the client key during the refresh token flow. Any client attestation JWT for the same client key issued by any attester the AS trusts. If this is the actual intention of the requirement, even after the original client attestation JWT expires and/or even after the attester ceases its service, the refresh token can be used with a new client attestation issued by any attester the AS trusts. In this case, AS implementations would check the JWK thumbprint of the client key only during the refresh token flow and would not check whether the attester is identical to the one of the previous client attestation JWT. FYI: defines a mechanism to bind an X.509 certificate to an access token. The specification states that a JWT access token should include (which represents the SHA-256 thumprint of an X.509 certificate) in its payload if the access token is bound to a certain X.509 certificate. It results in that certificate-bound access tokens and refresh tokens expire when their X.509 certificates expire and that renewing X.509 certificates for the same subject does NOT revive the access tokens and refresh tokens. Therefore, client applications have to go through an authorization flow again to get a new access token once the X.509 certificate bound to the previous access token expires. There are pros and cons. The requirement will need to be rephrased depending on what the "refresh token binding" wants to achieve.
Yeah, the statement "The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued." is problematic and needs to be removed or rephrased. The intent, as I understand it from previously discussing/pushing the issue of RT binding for this draft, is that the RT needs to be bound to the client instance. And that means binding the RT to the client instance's key. I think Tobias didn't want to go so far as saying that b/c he thought it was too inflexible. But the client instance's key is currently the only thing here that uniquely identifies the client instance.
NAME is correct around the intent here, I agree the wording makes it unclear so it should be clarified that the binding is to the client instance key used when the RT was issued.
Why not just use the same client attestation JWT? That would not require any client instance identification and is also not a privacy issue. urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation -> urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation Originally posted by NAME in URL
Related to . The problem with this model is that the refresh token if bound to the client attestation JWT then limits the RT lifetime.


Minor language tweaks aligning more to RFC 7521 in how the client authentication mechanism is defined as to not limit its application to only being used at the token endpoint.
There is an idea to send the Client attestation already in Authorization Request or PAR instead of with the Token Request. I see the following advantages: the client attestation could act as some kind of mobile capability descriptor, thus allowing the Authorization Server(Issuer) to check these before the user performs user authentication, otherwise this could result in poor UX as the user authenticates and the AS realizes only afterwards in Token Request that the level of client attestation is not enough (e.g. wallet can only handle key type xyz or LoA low) I see the following disadvantage: some flows do not require Authorization Request the user usually does not give consent before sending Authorization Request
The client attestation can for sure be used to authenticate with PAR. The HAIP already requires that.
The draft just needs to be clarified that this is a general purpose client authentication method that can be used with any interaction with an AS that is requiring or making use of client authentication.


As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.


URL
IETF drafts are expected to not exceed 72 characters per line. The diagram in the Introduction currently takes 91


Add security consideration for replay attack prevention and add nonce as optional value for PoP JWT URL
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
What about using the authorization code or pre auth code as suggested in our demo?
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code.
How many implemantations out there actually use different grant types than auth-code? Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested. NAME What's your opinion on this?
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.
discussion on 23.05 is leaning towards DpoP-style error providing nonce
can we please bring this issue forward, it is very important? I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint.
Update provided in
PR
PR


This PR makes explicit an already implicit feature of the specification - that it is not possible to rotate the confirmation key. URL) -->
NAME NAME Any reason this can't be merged?
Waiting for NAME approval
Currently section 5.2 states: In the case that the original client attestation JWT has expired, what should happen? If it is acceptable for the client to re-use the same key in the "cnf" field across attestation JWTs, then the client can easily generate a new attestation JWT with the same "cnf" key. But if the client needs to use a fresh "cnf" key, then I can think of three options: Define a flow which endorses the new "cnf" key with the old "cnf" key. Define a field in the client attestation JWT that contains a unique identifier for the client instance, and use that identifier to bind the refresh token to the client instance. Explicitly don't permit this in the specification, add text to the specification that makes it clear that the "cnf" key must stay the same across refreshed client attestations. My preference would be for option 2.
Currently the client instance needs to go back to the client backend and request a new client attestation JWT bound to the same key used in the old JWT. In general because we are effectively using the client instance key to identify the instance at the authorization server this makes key rotation of the client instance key difficult with active refresh tokens. 1 feels too complex, 3 is an option and NAME and I have discussed 2 before. The flip side to consider with option 2 is the privacy implications of formally electing to track client instances, personally i'm not convinced its a bad idea but we should carefully consider the impact.
Do we? I had assumed the AS identifies the client by the value. I don't see a need to identify a client instance.
the forth option is to have long living client attestations, which in my opinion is no problem the client should then use different attestations with different ASs
This just makes explicit the tracking of client instances that already existed through the requirement for the "cnf" key to stay the same over attestations. This is really a decision for the use-case in my opinion. In the context of software integrity being established through the client attestation, it is trivial to inject malware after the generation of the attestation, so some in some cases it may be a requirement to have fresh attestations.
Isn't the AS identifying the client also by the refresh token itself? I dislike option 2 due to the privacy implications. As any optional fields in the client attestation JWT are valid, profiles could still use this option, but it should not be a good requirement in my opinion. I see two options: A: the wallet initially gets one client attestation and uses the cnf key over a longer period to bind a sequence of refresh tokens to it. -> similar to option 4? B: the Wallet initially gets one client attestation and the AS binds the first refresh token to the cnf key. When it uses the refresh token, it also provides a new client attestation with a new cnf key and the AS binds a new refresh token to this new key. -> similar to option 1?
Well the current language doesn't actually guarantee that the AS can track the client instance (which is a good thing IMO), as the instance can in many common cases, rotate the keys it uses in between fetching tokens. But in the event a client instance is exchanging a refresh token for a fresh access token and potentially another refresh token, the client instance must authenticate using a client attestation JWT with the same key in the cnf claim that was in the original attestation used when the refresh token was obtained. This ensures one client instance can't use another client instances refresh token. So in this case the AS can track that the client instance who obtained the refresh token is the client instance now requesting to exchange it for a new access token, which is desired from a security perspective. As I said above in response to Torsten's point, using the key instead of an explicit claim means a single client instance could actually use multiple keys over time meaning the AS can't track the client instance across all of those interactions. The concern if we make an explicit claim in the client attestation JWT for identifying the client instance, is that implementations won't rotate this identifier over time thus meaning the instance would be tracked. Ironically if your goal is to reduce the ability of the AS to track the client instance over time, this option will in fact enable that as the attestation itself becomes the tracking vector. Agreed, the additional requirement of requiring the same client authentication method with the same key just means that obtaining the refresh token alone is not enough for another instance to be able to exercise the refresh token, it doesn't materially change the ability for the AS to track the client instance because as you highlight the refresh token itself creates the same possibility for correlation.
I think this is basically my option 3. Unless there is a mechanism to issue a refresh token that I am not aware of, it is not possible to rotate keys according to the current language. The spec states: This is what I mean by "This just makes explicit the tracking of client instances that already existed through the requirement for the "cnf" key to stay the same over attestations."
I don't think rotation of the key within the lifetime of a refresh token is something that needs to be accounted for. So my preference would be for option 3 (which is how it functionally is now but could be made more explicit in the text). Adding an explicit claim in the client attestation JWT which identifies the client instance, i.e. option 2, would be okay too. But I think it'd get complicated/confusing to describe it in the spec.
By saying you can't rotate the key within the lifetime of a refresh token, I think this means that you cannot rotate the key without starting from scratch at the authorization endpoint. I just wanted to make sure that is what you meant?
Basically yeah, I think so. Rotating the the key would mean you'd have to go back to the authorization endpoint. That seems acceptable/reasonable. Maybe it's too narrow of a view but it seems like if there's a reason to rotate that key then reauthorizing is probably needed or at least acceptable anyway.
I'm not sure that's true. IMO authorization is more of a user-identification concern, the rotation of the key is a client-security concern. Saying that, I think I agree that it's probably acceptable to say key-rotation isn't possible without returning to the authorization endpoint. Given this I would suggest we add a sub-section to the Implementation Considerations section, something along the lines of this:


Based on the discussions had at IETF 119 in the OAuth WG, this PR attempts to make the following changes to the draft Move away from usage of the assertion framework defined in RFC 7521 and RFC 7523 for conveying the client attestation and client attestation pop. Instead use two newly defined HTTP headers OAuth-Client-Attestation and OAuth-Client-Attestation-PoP for conveyance in an HTTP request, akin to how DPoP works. Explicitly mention this mechanism could be used in a variety of places including with a resource server. Note, there are still many outstanding items I would like to add, however I felt this PR was already big enough as it is, these include Error responses for the token endpoint Optimisation for when this mechanism is used with DPoP to avoid having to send two PoP's Formalising whether this mechanism still constitutes a form of client authentication
For some reason it seems to not create an html version? This is the rendered text: URL
I think there were potential objections mentioned about moving to headers as to whether we'd run into size limits (I think 8 KB was mentioned as a common restriction) and people felt jwts with embedded x5c headers etc may get close to these limits?
NAME indeed. We may have a client attestation with an huge x509 certificate chain or an openid federation trust chain with several metadata, trust marks and jwks. I don't see the benefit of moving from what it is actually more efficient (wa~wa-pop) more over, technically we can have multiple client_assertions that embedes their pop (using ~), while having multiple http headers that divide attestation from pop forces the implementations to loop all the assertions and all the pop to find the matching ones
Added client instance definition and updated to use US based spelling of authorization instead of authorisation.
NAME NAME I can understand the desire to want to use X.509 certificates to validate the client assertion (e.g as an alternative key resolution mechanism to resolving a JWKS document from a domain), however I don't see how the certificate chain would be more then 1 certificate (maybe 2) in length (bearing in mind the root certificate(s) would be communicated to the issuer out of band and pre-trusted for the client). W.r.t other aspects of the client attestation or client attestation pop being too big for an HTTP header could you elaborate on what you see as the contents of your attestation NAME Because IIUC you perhaps want to use the client attestation to convey all client metadata? If that is the case IMO the client attestation isn't for this purpose, client metadata should continue to be communicated outside of these attestations with the pre-existing mechanisms we already have defined. Finally even if we did begin to encroach on header payload limits with a client attestation, we aren't talking about hard limits here, rather just the default maximums that common web server platforms have configured, which can always be adjusted.
there some point for clarification assertion weight: a client assertion may have a x5c or an openid federation trust chain within its JWT header. This is an issuer's choice, allowed by RFC 7515 that might be not supported by httpd maximum header body size, that's a deployment/configuration choice that might be different within different domains. chain length: it could be assumed that a chain may not exceed 2 or 3 certificate breaks. This depends on the number of intermediates, an aspect that falls outside the technical specification and is determined by the federation's topology and composition. client metadata: we have some required claims in the wallet attestations and the possibility to include any other custom claim or any other claims pertaining the wallet capabilities or anything else related to the trust framework. My comment is not related to assertion payload, but to the previous point 1 and 2. However, the payload also impacts in the assertion weight, as pointed out at point 1. The missing point concerns the processing of multiple DPoP tokens within the same request. Handling multiple DPoP tokens necessitates a loop to identify the one that matches a specific assertion. This introduces additional computational and development efforts not present in the current approach (WA~WA-POP), which directly associates an assertion with its proof of possession (PoP), facilitating a straightforward and efficient identification of matching pairs.
Ok great so do we agree that this isn't an issue because servers are freely able to re-configure the max header size based on their application? Because it isn't a hard limit.
Understood but based on the above point is this actually an issue if the limit on header size isn't a hard limit?
Right but to be clear, the current draft does not handle multiple wallet attestations either though so I think this a new requirement that we should discuss separately, would you mind opening a seperate issue?
The issue extends beyond the realm of multiple wallet attestations, as there could also be multiple DPoP tokens involved. An additional consideration, which we have not yet fully addressed but may emerge as a future requirement, is the scenario where a wallet instance operates under more than one trust framework, necessitating specialized assertions for each. While we have consciously chosen to limit the scope to a single wallet attestation to simplify implementation, it's important to acknowledge that this decision does not preclude the possibility of requiring multiple assertions in the future. Implementers may need to adapt or extend the specification to accommodate such needs. However, to avoid digressing further, let's focus on the matter of handling multiple DPoP headers for now. The approach currently documented, which aims to streamline the process by limiting it to a single attestation, is designed to offer the same benefits while minimizing computational overhead.
While it is possible to reconfigure these options, it is important to keep default values of the wide-spread implementations in mind to allow an easy path for adoption. I took the time to look at some of the frameworks I would say are good indicators: nginx: --> 8KB for 1 header max envoy (used in istio): --> 60 KB for headers URL --> 16KB for headers traefik: --> re-uses go/http: 1MB for headers --> After looking at this, I would say we can go with headers
An OpenID Federation trust chain with two intermediates, the trust anchor entity configuration with a long list of trust mark issuers and the leaf entity configuration with a very verbose configuration, such as an AS + Openid4VCI + OpenID4VP (considering an EAA provider), with policies and a consistent number of trust mark might be 20KB. A serialized X.509 certificate chain, with 4 intermediates, custom extensions and QWACs ... Considering each certificate up to 2.2KB, might it be 8.8KB? (please, consider that openid federation brings policy languages, trust marks and multiple protocol specific metadata) I'm worried about these aspects: loop required for parse/matching the correct DPoP when multiple DPoP are present, while WIA~WIA-POP doesn't bring this problem. What's the benefit of having this breaking change that reduce the flexibility while increasing the complexity? size limitations: Do we have to imagine to standardize something upon the assumption that a federation topology should not have more than 2 or 4 or 8 intermediates, since this decision is out of scope on this specification.
A bit off-topic for the current discussion: We need to fix the examples - they are way too long which breaks the rendering/conversion and will cause problems with the datatracker. I do believe that this is also the reason why the html file was not created.
Note that rfc9449 does not allow for multiple DPoP headers. It could maybe have been stated more clearly but is kinda implied and was absolutely the intent of the RFC overall and specific text like URL
NAME as I implied with my earlier comment, the current draft text doesn't support multiple attestations so I don't view this proposal to shift to headers as removing functionality, it appears this is a new usecase and I think we should discuss it in a seperate issue. No I dont think we do, what was identified above is that there is no size limit on headers in HTTP rather defaults that servers apply which can be adjusted, in reality web servers also apply limits to the body of an HTTP request (although often much larger then what is allocated for headers).
Discussed with NAME I will add an implementation consideration around the default size limits for HTTP headers.
NAME what about using compressed values? unfortunately this sounds like giving a solution that may bring other problems, at the same time we can consider zlib (RFC 1950) for doing this.
Something broke with linking the html rendered versions properly Rendered html: URL
It just (re)occurred to me that specs defining new HTTP headers (which the cool kids call fields nowadays) are supposed to request their registration in the . I don't want to hold up this PR for this but will create an issue from this comment so as not to lose track of it.
I do believe there should be a discussion about terminology (attestation vs assertion) as it seems to create quite a bit of confusion, but I do think a different issue/PR is better suited for that. Minor nit: Client Attestation seems to be used in lower and upper case somewhat inconsistently. Should every usage be upper case (e.g., also client attestation mechanism)?


"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."


The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.


From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.


As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.


Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.


This fixes the definition, it incorrectly used "fragment" when it meant "body" as later shown in section-3.2


cc NAME
From Pieter's review: Since "presentation methods" has come to have a new meaning. The language above is consistent with the language used in 6750.
The text is clear and brings better alignment with the name of the parameter.


cc NAME
From Pieter's review: "between the host and path components of the protected resource's resource identifier, as shown in Section 3.1 below"
Looks good to me.


Cc NAME
Section 3.3 should reference the attack described in section 7.3 URL And evaluate whether it makes sense to add a back reference from 7.3 to 3.3.
Looks good to me.


cc NAME
[ ] Step 5, add reference to how to validate: "...according to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3" [ ] Step 5.2: rephrase to "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained."
Looks good to me.


cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.


Cc NAME
well that's one way to solve it!
URL Change "applications" to "deployment" for clarity
Looking at making the change, there are ~12 places we'd be changing "application" to "deployment" and it's not clear that it would improve the readability or clarity of the text. Furthermore, I'll also point out that this is the language used in RFC 8414, and it seems to have worked for people there, so I'm reluctant to make this change, given I don't think it would be a significant enough improvement to warrant being different. cc NAME
My comment about this section was that it was generally quite hard to follow, not that "application" should be replaced by "deployment". This sentence took a while to parse: "Different applications utilizing OAuth protected resources in application-specific ways may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications. " I think the intent here is to say that an application may be composed of different OAuth protected resources, and each of those may have their own protected resource metadata, and if this is the case, your describing a scheme on how the application may expose the resource metadata to clients for each of the underlying OAuth protected resources. If that is the intent, changing from "application" to "deployment" may not help (these are different concepts). Perhaps just an introductory sentence for that paragraph - something like: "An application may access multiple OAuth protected resources in order to complete an operation. Each OAuth protected resource may have their own resource metadata. In this case, the application may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications to enable a client to obtain the resource metadata for each of the underlying resources. As I write this, I think my confusion here was more about the lack of clarity on the relationship of the application (which may itself be an OAuth protected resource?) and the OAuth protected resources (which it relies on to perform an action).
NAME talked about this in Rome. The term "application", as used, encompasses all the components used to accomplish the task for the use case. That can include OAuth clients, authorization servers, and protected resources, inclusive of the code running in each of them. Applications are built to solve particular problems and may utilize many components and services. I could add an introductory remark derived from the above, if that would work for you. (Although I would try to make it more concise.)
Looks good to me.


Removed extraneous paragraph about downgrade attacks discussing an issue that's already addressed elsewhere in the specification.


for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!


from review comments from John Scudder
Please also add John Scudder to the acknowledgements.


... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!


maybe adjust the language around DEFLATE and ZLIB per Originally posted by NAME in URL
Copied over, to have everything in the issue here: This is the current text: This is the proposal: >The complete byte array is compressed using DEFLATE {{RFC1951}} inside the ZLIB {{RFC1950}} data format. Implementations are RECOMMENDED to use the highest compression level available. I agree that the current text is a bit weird and I wasn't really sure how to formulate it better when writing it.
More context copied over via Screenshot: !


Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references


Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens


This PR adds: CBOR/CWT encoding for status list and status list info Example implementation for CBOR/CWT Not included yet: examples for referenced tokens (COSE, CWT) but that should be trivial to add. URL
The decoded cbor is: The list does not seem to be valid zlib.
I've tried with cyberchef and it seems to work for me: -> zlib inflate =
You are right, I probably tried on the hexstring :D
I assume there will be a lot of comments. I had some troubles with the claim language for non-CWTs btw. Please review and give feedback. NAME NAME NAME
I was wondering whether it would be better to define a CDDL for Status, StatusList and StatusListInfo. Basically, having a high-level CDDl description of all objects and then having some specific sections for JWT, COSE, CWT that define how they are used in the corresponding objects.
Also keep in mind that claim for CWT will require IANA to assign us an integer number, so we can use it in the CWT.
There is a problem with the width of the CBOR diagnostic notation examples. The datatracker only allows a width of 72, but cborg defaults to 100 and apparently can't be configured in CLI mode.
I can write a small JS script that uses the cborg library and configures the width to 72. Would this be even possible? I didn't check by myself.
Yes that would be possible and is the only option I have found so far. I was searching for a pure python solution (which would be cleaner imho) but that seems to be not possible right now.
The abstract, intro, diagrams wrt referenced tokens description should refer to COSE and JOSE instead of CWT/JWT. Otherwise, non-CWT COSE objects such as ISO 18013-5 MSO cannot use this spec. Same applies to SD-JWT VC encoded secured using JWS.
We adjusted the terminology already, but the text in the introduction is not matching yet. In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.


adds ttl to the generated examples: Rendered verison: URL
Should be fine now, with some minor fixes to rendering and adding the proposed values. Can you please check again NAME
It appears the example uses a text string instead of a byte string for the idx value.
Good catch, the referenced token example is wrong!


Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.


The first and second sentence of this description seem contradictory to me. The first sentence seems to state that (all?) Status List Tokens should have a unique identifier included as their claim. The second sentence directly contradicts this uniqueness requirement. Perhaps I'm misunderstanding what is meant by 'uniqueness' in the first sentence, but in that case the language is quite ambiguous. As the claim seems to have been added solely for including the from the Referenced Token in the Status List Token (as described in ), perhaps the sentences should simply be reworded to not mention uniqueness. So something like: : REQUIRED. The (subject) claim MUST be equal to the claim contained in the claim of the Referenced Token.
The is basically the URI by which the Status List Token is retrieved. As Status List Tokens may be downloaded for offline use, further re-transmission or archiving, its important to also store the URI in the Token, such that it can be compared by others to the of the claim of the Referenced Token. I see that the text may be confusing, it should be clearer as "URI" may be better than "unique string identifier" and URI is unique anyway. How about: : REQUIRED. The (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the claim contained in the claim of the Referenced Token.
Yes thank you, this wording clears it up. If you wanted to be very precise instead of you could write . But perhaps my suggestion is too verbose, what you've written gets the idea across.


"endpoint" is still mentioned in there, unsure we we completely want to get rid of it
Section '8.1. Status List Request' currently states: This seems redundant when the endpoint is used to retrieve a Status List Token, as the Token's integrity is already guaranteed by requiring it to be signed using an asymmetric cryptographic algorithm. If requiring TLS was intended for providing confidentiality of the Token, this seems unnecessary. The endpoint is publicly accessible - there does not seem to be any client authentication mechanisms described for it - thus the Tokens could be retrieved by anybody.
Hi NAME , thanks for the feedback! I think you are correct that we could relax using TLS when a Status List Token is queried. However, if an unsigned Status List is returned, we need TLS as an integrity mechanism.
Yes I vehemently agree :) Btw, perhaps the issue is a bit broader that just permitting plain HTTP when obtaining Status List Tokens. I don't think it's currently explicitly stated in the specification whether a Status List Provider should/must simultaneously provide both plain Status Lists and Status List Tokens. Ie the standard states that an RP should use the Accept-Header to indicate the requested response type, but it does not specify what the Status List Provider should do if it is unable to provide the requested response type. I think this is somewhat relevant under this issue as: if you were to simply add a sentence to the spec permitting plain HTTP for Status List Tokens then an Issuer would have to decide whether to put an HTTP or HTTPS URI in the claim of the Referenced Token but this somewhat contradicts with the Accept-Header mechanism which would seem to indicate (to the reader of the spec) that it's up to the RP to choose the response type. Perhaps the Issuer should explicitly specify supported response type(s) in the claim of the Referenced Token? Ie there could be an additional attribute in the object under the claim specifying the supported formats. Such an attribute could prove beneficial in other regards as well. For example, I don't immediately see an use case where an Issuer/Status List Provider would be providing cbor/cwt Status Lists for JOSE Referenced Tokens.
Section mentions Status List Endpoint. The term is not mentioned elsewhere in the specification nor is it defined.
Thanks for the feedback. Discussion Editors Call: connected to the discussion whether Status List Provider is an entity that shall be described in the spec intend to clarify the term for next iteration


Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex


Rendered Version: URL
COSE typ is now registered in IANA. Because of that, the TBD could be removed.


Adds a claim key for used in the status list token in CWT format and fixes the reference.


Status List claim was referencing Chapter 4.1 instead of Chapter 4, which made it ambiguous whether to base64url-encode or not


Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?


Rendered version: URL
We should probably add a small section mentioning that should be set to when explaining the endpoint.


Micha proposed to change REVOKED to INVALID, as it gives less intention whether this is a permanent state and the issuers could reflect a suspension also with a 1bit size status list as well
I'm in agreement with Kristina, the more I look at this the more I think we should have one possible enumeration of statuses rather than allowing every issuer to define their own, the question then becomes how big that set needs to be as it controls how many bits are allocated to each credential in the status list.
I'm fine with defining the first bit as valid/invalid. I think providing the option for additional bits offers benefits with acceptable tradeoffs
I've made some changes, please recheck NAME NAME
umm I thought we agreed to remove the concept of the "typ" attribute.. so no and no .
Yeah that was captured here NAME URL
But I assume the Status List Token will have a JOSE header to properly distinguish it from other JWTs, right?
I approve, but moved to separate issue
NAME typo on my end. yes, JWT should be typed ( claim present), the current spec also introduces a body claim as far as I can see, which is what I am not in agreement with.
NAME I am confused. so the idea is to merge this PR and then remove the "type" JWT claim in PR ?
comment edited, I got confused here as well. There is an issue open already as a task and I would like to not blow up the PRs too much
NAME ready for merge
I am a little confused with calling "VALID", "INVALID" Status List , but agreed this should be mergedOne minor typo


fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types


Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho


Questions for the encoding: base64 vs url-safe base64 bitwise encoding right now is least significant bit to most significant bit The part describing the bit-encoding still needs be rewritten In general: I searched a bit for better ways to encode/compress but in terms of simplicity and support for different programming languages, it seems some form of byte array and gZIP seem to be a pretty decent pick.
I've made a first implementation in Kotlin today. To me, it feels very natural to count Byte indexes up from 0 to size(whether this is left to right or right to left feels a little philosophical) and Bit indexes from right to left.
Imho we need another iteration on the description of the bit encoding, most likely with some form of ASCII art. I would prefer to do that in another PR- what do you think?


As the similar requirement was relaxed on SD-JWT, I think we should consider the same.


The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix


The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.


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.


yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change


Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.


We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL


after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art


fixes the examples to use constant timestamps in gzip encoding minor changes/fixes to the ascii art / code blocks


reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards


Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.


URL
As described in the title the size of the list (number of token statuses represented by the list) will have a significant impact on privacy related applications.
I see this is related to
Should we define a minimum size or give this as a recommendation in privacy recommendation?
use SHOULD for minimum size 16K


Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology


IANA Consideration to register JWT Claim names and media types URL
Propose and as media types
same for jwt types?
Note that JWT values are actually media types URL which is a little odd sometimes but that's how it is - so you don't need anything different in terms of registration for a jwt type b/c it is a media type. And the JWT BCP does recommend explicit typing using URL for better or worse, which would suggest that be registered. But it and would also probably have utility in places like HTTP and headers so would make sense to register both. There are some media-type-registration requests in SD-JWT that could be borrowed from URL or you can look at entries in the registry URL


Change typo in Status List Token sub claim description URL
The in the "Status List JWT Format and Processing Requirements" section has 'The JWT MUST contain a "sub" (subject) claim that contains an unique string identifier for that Referenced Token.' but I believe it should be "... unique string identifier for that Status List Token."
that's correct, thanks for pointing this out Brian


gathering some ideas on privacy and security considerations
Looking good NAME you should be able to run 'make fix-lint' locally to fix the whitespace issues
Need to remove the trailing whitespaces for the markdown tooling to be happy


and . Switches to zlib instead of gzip encoding and adds the recommendation to use the best available compression.
I'm working on a TypeScript implementation of this spec, and have the encoding / decoding of the status list implemented. It seems to work based on the example in the spec and the example python scripts, with one slight difference. When I encode either the 1 or 2 bit example it will output one character difference , while mine outputs an . The decoding seems to work fine, and maybe this is a gzip thing, but I'm wondering if the examples use certain gzip features to get this output? I've adapted my implementation to use compression level 9 (default for python lib) and set the mtime to the same value The input byte array is the same as for the python implementation and the examples in the spec, so it's really something that is happening during the gzip encoding (the output byte array here is different) any idea what is going on here? The implementation and tests can be found here: URL
Seems to be a difference in the header - from the position I would assume the timestamp (even though you seem be setting it to the fixed value used in the examples in the draft)? There is also a header entry for the operating system - that would also be a very likely candidate for the difference. I will take a look at it when I am back from IIW. We were discussing switching from gzip to zlib (or deflate directly) for that reason - we don't really need these headers and most languages seem to support both gzip and zlib (which was our concern when we initially thought about this). Related Issue:
Thanks for testing! There is a header as well in zlib, but it's considerably smaller. The zlib header does not include a timestamp which makes it better for reproducible results and test vectors. I think we should also give a recommendation for the used compression level, I suspect either default or highest. It would be interesting if the underscore vanishes in zlib?
I changed the python implementation to use zlib with level 9 and did the same for your typescript implementation --> both resulted in the same: We should really change that imho (and also add the text to recommend compression level).
I'm a proponent of using zlib instead of gzip. As suggested in the other issue, we don't really need the other metadata. And the result is smaller as well :)


This feedback comes from applying the Status List to an implementation of a general OAuth 2.x server issuing JWT Access Tokens. Such implementation will typically not keep record of any issued JWT Access Tokens (their claims, expiry, etc) until they need to be revoked due any reason, e.g. getting leaked or just being explicitly revoked by the client. In such cases the issuer considers the token as VALID when issuing the Status List but this state will not necessarily reflect the token's validity as per the JWT validation rules for claims like nbf or exp. This is important to point out so that the status list is not mistaken for an alternative to actually validating the referenced token's claim set.
NAME could you merge with main and add a line to the document history please
Not a member, cannot merge.
I meant sync, sry. But I can add the history on main also.
NAME Please review and merge if you approve
Looks good to me. It might be better positioned in a dedicated Verification Processing section once we have that but its good for now


Adds access token as an example use-case for status list.
Aaron says that there are zero mentions of the term access token and proposes to mention JWT accesstokens as a possible usecase