Skip to content

Commit a25e6a2

Browse files
author
ID Bot
committed
Script updating archive at 2025-03-02T00:19:01Z. [ci skip]
1 parent 9538284 commit a25e6a2

File tree

1 file changed

+182
-4
lines changed

1 file changed

+182
-4
lines changed

‎archive.json‎

Lines changed: 182 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2025-02-27T00:17:29.359279+00:00",
3+
"timestamp": "2025-03-02T00:18:49.991273+00:00",
44
"repo": "oauth-wg/draft-ietf-oauth-status-list",
55
"labels": [
66
{
@@ -5236,7 +5236,7 @@
52365236
],
52375237
"body": "In #228, C2bo wrote:\n\n> The claim \"aggregation_uri\" is meant as a way to allow efficient caching for RPs, not for alternative URIs \n> - it points to all relevant status lists for an issuer or specific referenced token type.\n\n\"aggregation_uri\" is defined in 4.1 as:\n\n> aggregation_uri: OPTIONAL. JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token. \nSee section 9 for further detail.\n\nSection 9 (Status List Aggregation) states:\n\n> Status List Aggregation is an optional mechanism to retrieve a list of URIs to all Status List Tokens, allowing a Relying Party to fetch all relevant Status Lists for a specific type of Referenced Token or Issuer. \n\nThese two descriptions are not aligned with section 4.1. **The case of the Issuer is not mentioned in section 4.1**.\nHowever, in section 9, the sentence mentions: \n> all relevant Status Lists for a specific type of Referenced Token **or Issuer**. \n\n Then comes some questions.\n\nHow can the Relying party retrieve either: \n\na) all relevant Status Lists for a specific [type of] Referenced Token, or\nb) all relevant Status Lists for an Issuer ?\n\nIn the first case, how long should \"all relevant Status Lists\" for a specific type of Referenced Token be accessible ? \nSame question for \"all relevant Status Lists\" for an Issuer.\n\nIf the case of the \"Issuer\" is indeed supported, there should be some additional text to warn the Issuers about some consequences when this claim is supported. For example:\n\n> \"All relevant Status Lists for an Issuer\" allows a Relying Party to know how many Referenced Tokens have been issued by an Issuer and are either valid, suspended or revoked at an instant of time. This can reveal also the number of entities that have been registered. Issuers should be warned of the consequences before choosing to support this optional claim.\n\n\nFinally, the argument is that this claim is \"meant as a way to allow efficient caching for RPs\". However, I still have difficulties to understand the usefulness of this optional claim when the JSON String contains a URI to retrieve the Status List Aggregation for this Referenced Token.\nCaching is pretty well supported by the ttl claim:\n\n> * ttl: OPTIONAL. The ttl (time to live) claim, if present, MUST specify the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved. \n\n",
52385238
"createdAt": "2025-02-03T09:45:58Z",
5239-
"updatedAt": "2025-02-25T08:07:38Z",
5239+
"updatedAt": "2025-03-01T14:46:10Z",
52405240
"closedAt": null,
52415241
"comments": [
52425242
{
@@ -5308,6 +5308,34 @@
53085308
"body": "\n> I think there is some misunderstanding on how the aggregation_uri currently works:\n> It is a uri that is provided either by metadata (.well-known etc) or within a Status List Token itself.\n> When resolved, it contains a JSON array with a list of URLs to Status List Tokens.\n\n> This now becomes understandable, but this is not what the text was saying:\n\n> JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token or Issuer.\n\n> This text is from the draft an clear enough to me. What's missing?\n\nThe draft is unclear as it does not contain the following wording: \n\n> \"JSON array with a list of URLs to Status List Tokens.\n\nSome text like below would be more understandable:\n\n> uri that is provided either by metadata (.well-known etc) or within a Status List Token itself.\nWhen resolved, it contains a JSON array with a list of URLs to Status List Tokens.\n\nYou wrote:\n\n> There may be more than one \"latest\" Status List Token, if the Status Issuer is chunking these Referenced Tokens into multiple Status Lists for scalability. Therefore, aggregation_uri may contain multiple URIs to multiple Status List Tokens. If one of them fails for whatever reason, still continue with the others.\n\nThe above explanation is using the word \"chunking\": \n\n> \"if the Status Issuer is chunking these Referenced Tokens into multiple Status Lists for scalability\".\n\n I made a search on the term \"chunk\" and, in the draft, I found the following text:\n\n> The Status List Issuer may chunk its Referenced Tokens into multiple\n> Status Lists to reduce the transmission size of an individual Status\n> List Token. This may be useful for setups where some entities\n> operate in constrained environments, e.g. for mobile internet or\n> embedded devices. The Status List Issuer may chunk the Status List\n> Tokens depending on the Referenced Token's expiry date to align their\n> lifecycles and allow for easier retiring of Status List Tokens,\n> however the Status Issuer must be aware of possible privacy risks due\n> to correlations.\n\n\"chunk\" is a term I am not familiar with. \n Cambridge dictionary: a part of something, especially a large part. \n North American: divide (something) into chunks. \n\nThis does not help me to understand why \"chunking\" is used and what is being \"chunked\".\n\nThe Issuer can decide to place THE status of a Referenced Token in any SLT depending upon a criteria of its is own choice. \nIt is is NOT the job of the Status List Issuer to decide: it is the job of the Issuer. \n\nThis still does not explain why THE status of a Referenced Token should be placed into \"more than one SLT\". \nTo make an analogy, when using CRLs, there is one and only one (base) CRL referenced in an X.509 PKC and if it fails \n(whatever the verb \"fail\" may mean) then there is no \"continuation\". \n\nLet us make things simple and do not attempt to make things over complicated.\n\nThe text that is \"chunk-related\" should be removed.\n\nThe text that is mentioning \"types of Referenced Tokens\" should also be removed.",
53095309
"createdAt": "2025-02-25T08:07:37Z",
53105310
"updatedAt": "2025-02-25T08:07:37Z"
5311+
},
5312+
{
5313+
"author": "paulbastian",
5314+
"authorAssociation": "CONTRIBUTOR",
5315+
"body": "> > I think there is some misunderstanding on how the aggregation_uri currently works:\n> > It is a uri that is provided either by metadata (.well-known etc) or within a Status List Token itself.\n> > When resolved, it contains a JSON array with a list of URLs to Status List Tokens.\n> \n> > This now becomes understandable, but this is not what the text was saying:\n> \n> > JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token or Issuer.\n> \n> > This text is from the draft an clear enough to me. What's missing?\n> \n> The draft is unclear as it does not contain the following wording:\n> \n> > \"JSON array with a list of URLs to Status List Tokens.\n> \n> Some text like below would be more understandable:\n> \n> > uri that is provided either by metadata (.well-known etc) or within a Status List Token itself.\n> > When resolved, it contains a JSON array with a list of URLs to Status List Tokens.\n\nNo, you still got it wrong. The Status List contains ONE URL in the `aggregation_uri`, that one points to the object described in Section 9 which contains the array of URLs to the other Status List Tokens.\n\n> \n> You wrote:\n> \n> > There may be more than one \"latest\" Status List Token, if the Status Issuer is chunking these Referenced Tokens into multiple Status Lists for scalability. Therefore, aggregation_uri may contain multiple URIs to multiple Status List Tokens. If one of them fails for whatever reason, still continue with the others.\n> \n> The above explanation is using the word \"chunking\":\n> \n> > \"if the Status Issuer is chunking these Referenced Tokens into multiple Status Lists for scalability\".\n> \n> I made a search on the term \"chunk\" and, in the draft, I found the following text:\n> \n> > The Status List Issuer may chunk its Referenced Tokens into multiple\n> > Status Lists to reduce the transmission size of an individual Status\n> > List Token. This may be useful for setups where some entities\n> > operate in constrained environments, e.g. for mobile internet or\n> > embedded devices. The Status List Issuer may chunk the Status List\n> > Tokens depending on the Referenced Token's expiry date to align their\n> > lifecycles and allow for easier retiring of Status List Tokens,\n> > however the Status Issuer must be aware of possible privacy risks due\n> > to correlations.\n> \n> \"chunk\" is a term I am not familiar with. Cambridge dictionary: a part of something, especially a large part. North American: divide (something) into chunks.\n> \n> This does not help me to understand why \"chunking\" is used and what is being \"chunked\".\n> \n> The Issuer can decide to place THE status of a Referenced Token in any SLT depending upon a criteria of its is own choice. It is is NOT the job of the Status List Issuer to decide: it is the job of the Issuer.\n> \n> This still does not explain why THE status of a Referenced Token should be placed into \"more than one SLT\". To make an analogy, when using CRLs, there is one and only one (base) CRL referenced in an X.509 PKC and if it fails (whatever the verb \"fail\" may mean) then there is no \"continuation\".\n> \n> Let us make things simple and do not attempt to make things over complicated.\n> \n> The text that is \"chunk-related\" should be removed.\n> \n> The text that is mentioning \"types of Referenced Tokens\" should also be removed.\n\nI'm ok to rename \"chunk\" into \"aggregate\".\n\nA Referenced Token's status is not put into multiple Status List Tokens, but many Referenced Token's statuses may be divided/spread/distributed across multiple Status List Tokens. Already today, some X509 CAs have more than one CRL, which is the same mechanism.\n\n",
5316+
"createdAt": "2025-02-28T17:56:10Z",
5317+
"updatedAt": "2025-02-28T17:58:03Z"
5318+
},
5319+
{
5320+
"author": "Denisthemalice",
5321+
"authorAssociation": "NONE",
5322+
"body": "It seems that we don't agree about the role of the Issuer and of the Status Issuer.\nIt is the Issuer that decides which SLT will be used for a given Referenced Token (i.e., it is not the Status Issuer).\n\nI still disagree with (or do not understadd) the following sentence: \n\n> The aggregation_uri contains a list of Status List Tokens - if fetching or validating one of them fails,\n> the others should still be processed\n\nIn addition, would you agree to remove the text that is mentioning \"types of Referenced Tokens\" ?",
5323+
"createdAt": "2025-02-28T18:24:01Z",
5324+
"updatedAt": "2025-02-28T18:24:01Z"
5325+
},
5326+
{
5327+
"author": "paulbastian",
5328+
"authorAssociation": "CONTRIBUTOR",
5329+
"body": "How the Status List Tokens are organized is primarily a technical task, therefore the Status List Issuer's. As the recommendation is anyway to randomize, there is no need for the Issuer of Referenced Token to give further guidance.\n\nI also don't agree to remove the text types of Referenced Tokens. Easy example: A goverment issuer is issuing multiple Credentials/Referenced Token, but police officers are only interested to cache the status information for driving licenses. Therefore it may make sense to have multiple Status List Aggregations per Referenced Token.",
5330+
"createdAt": "2025-03-01T14:41:15Z",
5331+
"updatedAt": "2025-03-01T14:41:15Z"
5332+
},
5333+
{
5334+
"author": "paulbastian",
5335+
"authorAssociation": "CONTRIBUTOR",
5336+
"body": "I added further explanations for aggregation_uri and renamed chunking in #272 \nIf you still disagree after this, please bring it up to the mailing list or bring it up in the IETF Bangkok meeting",
5337+
"createdAt": "2025-03-01T14:46:09Z",
5338+
"updatedAt": "2025-03-01T14:46:09Z"
53115339
}
53125340
]
53135341
},
@@ -5435,6 +5463,22 @@
54355463
"updatedAt": "2025-02-20T07:56:19Z",
54365464
"closedAt": null,
54375465
"comments": []
5466+
},
5467+
{
5468+
"number": 271,
5469+
"id": "I_kwDOJZ2aqs6sHgvm",
5470+
"title": "Update Acknowledgments",
5471+
"url": "https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/271",
5472+
"state": "OPEN",
5473+
"author": "c2bo",
5474+
"authorAssociation": "MEMBER",
5475+
"assignees": [],
5476+
"labels": [],
5477+
"body": "I'd like to add the people that have contributed/provided feedback in the past few weeks/months. Please give a thumbs up / comment here if you are ok with being mentioned in the Acknowledgments section.\n\nI might have forgotten people - please comment if you think someone else should be added.\n\n@rohanmahy\n@steffenschwalm\n@Denisthemalice\n@sschulz-t\n@cre8\n@mickrau\n@hannestschofenig\n@wbl\n@rifaat-shekh-yusef\n\n(also fix Giuseppe's spelling)",
5478+
"createdAt": "2025-02-28T16:57:41Z",
5479+
"updatedAt": "2025-02-28T16:57:41Z",
5480+
"closedAt": null,
5481+
"comments": []
54385482
}
54395483
],
54405484
"pulls": [
@@ -17769,13 +17813,147 @@
1776917813
"labels": [],
1777017814
"body": "Closes #268 ",
1777117815
"createdAt": "2025-02-23T17:50:26Z",
17772-
"updatedAt": "2025-02-23T17:56:48Z",
17816+
"updatedAt": "2025-03-01T09:14:47Z",
1777317817
"baseRepository": "oauth-wg/draft-ietf-oauth-status-list",
1777417818
"baseRefName": "main",
1777517819
"baseRefOid": "9459928c2eeb7a8edef727137bcb0b4c4c8159b2",
1777617820
"headRepository": "oauth-wg/draft-ietf-oauth-status-list",
1777717821
"headRefName": "status_list_def",
17778-
"headRefOid": "6594d79506541c6130c997c12b1371556c63274e",
17822+
"headRefOid": "22f0a2d354ae02e3ddbbb7b36a1a0a6528246756",
17823+
"closedAt": null,
17824+
"mergedAt": null,
17825+
"mergedBy": null,
17826+
"mergeCommit": null,
17827+
"comments": [],
17828+
"reviews": [
17829+
{
17830+
"id": "PRR_kwDOJZ2aqs6eB9uj",
17831+
"commit": {
17832+
"abbreviatedOid": "6594d79"
17833+
},
17834+
"author": "c2bo",
17835+
"authorAssociation": "MEMBER",
17836+
"state": "COMMENTED",
17837+
"body": "",
17838+
"createdAt": "2025-02-28T17:02:32Z",
17839+
"updatedAt": "2025-02-28T17:17:27Z",
17840+
"comments": [
17841+
{
17842+
"originalPosition": 5,
17843+
"body": "```suggestion\r\n: An object in JSON or CBOR representation containing a compressed byte array that represents the statuses of many Referenced Tokens.\r\n```",
17844+
"createdAt": "2025-02-28T17:02:33Z",
17845+
"updatedAt": "2025-02-28T17:17:27Z"
17846+
},
17847+
{
17848+
"originalPosition": 14,
17849+
"body": "```suggestion\r\nA Status List is a data structure that contains the statuses of many Referenced Tokens represented by one or multiple bits. The [first section](#status-list-byte-array) describes how to construct a compressed byte array that is the base component for the Status List data structure. The second and third section describe how to encode such a Status List in JSON and CBOR representation.\r\n```",
17850+
"createdAt": "2025-02-28T17:04:56Z",
17851+
"updatedAt": "2025-02-28T17:17:27Z"
17852+
}
17853+
]
17854+
}
17855+
]
17856+
},
17857+
{
17858+
"number": 270,
17859+
"id": "PR_kwDOJZ2aqs6M8TlK",
17860+
"title": "Add cddl for statuslist cbor encoding",
17861+
"url": "https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/270",
17862+
"state": "OPEN",
17863+
"author": "c2bo",
17864+
"authorAssociation": "MEMBER",
17865+
"assignees": [],
17866+
"labels": [],
17867+
"body": "Closes #267 \r\nI only added the CDDL for the StatusList object CBOR encoding which seemed to be the most important to provide CDDL for. I don't think CDDL for the CWT would help (and I didn't find many examples in other specs doing CDDL for CWT).\r\n\r\n@rohanmahy Would that work for you?",
17868+
"createdAt": "2025-02-28T13:50:58Z",
17869+
"updatedAt": "2025-02-28T17:23:07Z",
17870+
"baseRepository": "oauth-wg/draft-ietf-oauth-status-list",
17871+
"baseRefName": "main",
17872+
"baseRefOid": "9459928c2eeb7a8edef727137bcb0b4c4c8159b2",
17873+
"headRepository": "oauth-wg/draft-ietf-oauth-status-list",
17874+
"headRefName": "267-cddl-for-cbor",
17875+
"headRefOid": "b9734d455c5c994a28280baa72cc64883c0070c3",
17876+
"closedAt": null,
17877+
"mergedAt": null,
17878+
"mergedBy": null,
17879+
"mergeCommit": null,
17880+
"comments": [
17881+
{
17882+
"author": "rohanmahy",
17883+
"authorAssociation": "NONE",
17884+
"body": "> Closes #267 I only added the CDDL for the StatusList object CBOR encoding which seemed to be the most important to provide CDDL for. I don't think CDDL for the CWT would help (and I didn't find many examples in other specs doing CDDL for CWT).\r\n> \r\n> @rohanmahy Would that work for you?\r\n\r\nI proposed a one line change in the CDDL. `bits` can't take any arbitrary integer value. It has exactly 4 choices, so just enumerate them.\r\n\r\nUsing text string keys instead of integer keys is unconventional. I don't have an objection, as long as you are deliberately making that decision.\r\n\r\nI agree that anyone using CWTs does not need you to provide CDDL for a generic structure.\r\n\r\nThanks, -r",
17885+
"createdAt": "2025-02-28T14:31:01Z",
17886+
"updatedAt": "2025-02-28T14:31:01Z"
17887+
}
17888+
],
17889+
"reviews": [
17890+
{
17891+
"id": "PRR_kwDOJZ2aqs6eAY0d",
17892+
"commit": {
17893+
"abbreviatedOid": "ed86717"
17894+
},
17895+
"author": "rohanmahy",
17896+
"authorAssociation": "NONE",
17897+
"state": "COMMENTED",
17898+
"body": "",
17899+
"createdAt": "2025-02-28T14:24:13Z",
17900+
"updatedAt": "2025-02-28T14:24:13Z",
17901+
"comments": [
17902+
{
17903+
"originalPosition": 11,
17904+
"body": "```suggestion\r\nStatusList = {\r\n bits: 1 / 2 / 4 / 8, ; The number of bits used per Referenced Token\r\n lst: bstr, ; Byte string that contains the Status List\r\n ? aggregation_uri: tstr, ; link to the Status List Aggregation\r\n}\r\n```",
17905+
"createdAt": "2025-02-28T14:24:13Z",
17906+
"updatedAt": "2025-02-28T14:24:13Z"
17907+
}
17908+
]
17909+
},
17910+
{
17911+
"id": "PRR_kwDOJZ2aqs6eBvzE",
17912+
"commit": {
17913+
"abbreviatedOid": "1b0acae"
17914+
},
17915+
"author": "paulbastian",
17916+
"authorAssociation": "CONTRIBUTOR",
17917+
"state": "APPROVED",
17918+
"body": "",
17919+
"createdAt": "2025-02-28T16:38:07Z",
17920+
"updatedAt": "2025-02-28T16:38:07Z",
17921+
"comments": []
17922+
},
17923+
{
17924+
"id": "PRR_kwDOJZ2aqs6eB_AP",
17925+
"commit": {
17926+
"abbreviatedOid": "1b0acae"
17927+
},
17928+
"author": "rohanmahy",
17929+
"authorAssociation": "NONE",
17930+
"state": "APPROVED",
17931+
"body": "",
17932+
"createdAt": "2025-02-28T17:04:59Z",
17933+
"updatedAt": "2025-02-28T17:04:59Z",
17934+
"comments": []
17935+
}
17936+
]
17937+
},
17938+
{
17939+
"number": 272,
17940+
"id": "PR_kwDOJZ2aqs6NCOq-",
17941+
"title": "add diagram for Status List Aggregation for further explanation, rena\u2026",
17942+
"url": "https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/272",
17943+
"state": "OPEN",
17944+
"author": "paulbastian",
17945+
"authorAssociation": "CONTRIBUTOR",
17946+
"assignees": [],
17947+
"labels": [],
17948+
"body": "\u2026me chunking to divide up\r\n\r\nCloses #255 ",
17949+
"createdAt": "2025-03-01T14:44:33Z",
17950+
"updatedAt": "2025-03-01T14:57:15Z",
17951+
"baseRepository": "oauth-wg/draft-ietf-oauth-status-list",
17952+
"baseRefName": "main",
17953+
"baseRefOid": "9459928c2eeb7a8edef727137bcb0b4c4c8159b2",
17954+
"headRepository": "oauth-wg/draft-ietf-oauth-status-list",
17955+
"headRefName": "chunking",
17956+
"headRefOid": "26e324410782331a86c0d1ad39c4f01c118970e4",
1777917957
"closedAt": null,
1778017958
"mergedAt": null,
1778117959
"mergedBy": null,

0 commit comments

Comments
 (0)