Script updating archive at 2023-09-17T00:35:35Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2023-09-14T00:32:57.534317+00:00",
+  "timestamp": "2023-09-17T00:35:31.557169+00:00",
   "repo": "ietf-wg-scitt/draft-ietf-scitt-architecture",
   "labels": [
     {
@@ -1598,15 +1598,15 @@
       "labels": [],
       "body": "`application/problem+json` vs `application/json`\r\n\r\nhttps://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/60#discussion_r1148486103\r\n\r\nWhy?\r\n\r\nAre there any references for this design choice I can review?",
       "createdAt": "2023-03-26T22:20:37Z",
-      "updatedAt": "2023-09-06T00:12:25Z",
+      "updatedAt": "2023-09-14T20:59:06Z",
       "closedAt": null,
       "comments": [
         {
           "author": "pdxjohnny",
           "authorAssociation": "NONE",
-          "body": "Running into this issue in https://github.com/scitt-community/scitt-api-emulator/pull/27 as well.  Would be great to return an object in addition to or instead of a string. Or allow for other properties which would be fully content-typeable to a custom response object within the error response on claim insert failure.\r\n\r\nLack of this prevents an automated conversation to resolve issues with claim insertion. Human readable strings are great, but ideally a human doesn't even get involved and machines can auto remediate issues due to detailed failure reasoning. This way the a human readable string might only be needed after a failed machine driven insert conversation (more than one call response).\r\n\r\nFor example  if the identity is an OIDC token with an invalid subject, the policy error could say what the subject and or other fields should contain or be set to.\r\n\r\n- References\r\n  - https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-requiring-a-reusable-workflow\r\n  - https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows\r\n  - TODO there is an issue somewhere which mentions wanting `job_workflow_ref,repository_id,repository_owner_id` to effectively pin auth to a known workflow. Ideally this expands to attestable stacks, where stack is logged in SCITT, i.e. secure boot (example: [ChromeOS: Attesting Device Mode](https://www.chromium.org/developers/design-documents/tpm-usage/#attesting-device-mode)) and TEEs. A policy engine could require that a notary signed from an attested setup.\r\n    - `gh oidc-sub set --repo org/repo --subs \"job_workflow_ref,repository_id,repository_owner_id\"`",
+          "body": "Running into this issue in https://github.com/scitt-community/scitt-api-emulator/pull/27 as well.  Would be great to return an object in addition to or instead of a string. Or allow for other properties which would be fully content-typeable to a custom response object within the error response on claim insert failure.\r\n\r\nLack of this prevents an automated conversation to resolve issues with claim insertion. Human readable strings are great, but ideally a human doesn't even get involved and machines can auto remediate issues due to detailed failure reasoning. This way the a human readable string might only be needed after a failed machine driven insert conversation (more than one call response).\r\n\r\nFor example  if the identity is an OIDC token with an invalid subject, the policy error could say what the subject and or other fields should contain or be set to.\r\n\r\n- References\r\n  - https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-requiring-a-reusable-workflow\r\n  - https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows\r\n  - https://github.com/sigstore/fulcio/issues/305) mentions wanting `job_workflow_ref,repository_id,repository_owner_id` to effectively pin auth to a known workflow. Ideally this expands to attestable stacks, where stack is logged in SCITT, i.e. secure boot (example: [ChromeOS: Attesting Device Mode](https://www.chromium.org/developers/design-documents/tpm-usage/#attesting-device-mode)) and TEEs. A policy engine could require that a notary signed from an attested setup.\r\n    - `gh oidc-sub set --repo org/repo --subs \"job_workflow_ref,repository_id,repository_owner_id\"`\r\n  - `job_workflow_sha` may also be helpful for pinning to a release",
           "createdAt": "2023-04-27T21:17:15Z",
-          "updatedAt": "2023-05-05T21:09:52Z"
+          "updatedAt": "2023-09-14T20:59:06Z"
         }
       ]
     },