[{"author": "Aaron Parecki", "text": "<p><span aria-label=\"wave\" class=\"emoji emoji-1f44b\" role=\"img\" title=\"wave\">:wave:</span></p>", "time": "2025-03-18T06:01:37Z"}, {"author": "Orie Steele", "text": "<p>hi</p>", "time": "2025-03-18T06:01:46Z"}, {"author": "Arndt Schwenkschuster", "text": "<p><span aria-label=\"wave\" class=\"emoji emoji-1f44b\" role=\"img\" title=\"wave\">:wave:</span></p>", "time": "2025-03-18T06:01:51Z"}, {"author": "Filip Skokan", "text": "<p>hello *</p>", "time": "2025-03-18T06:02:03Z"}, {"author": "Matthieu Sieben", "text": "<p>Hi</p>", "time": "2025-03-18T06:02:18Z"}, {"author": "George Fletcher", "text": "<p><span aria-label=\"wave\" class=\"emoji emoji-1f44b\" role=\"img\" title=\"wave\">:wave:</span></p>", "time": "2025-03-18T06:02:18Z"}, {"author": "Andy Barlow", "text": "<p><span aria-label=\"wave\" class=\"emoji emoji-1f44b\" role=\"img\" title=\"wave\">:wave:</span></p>", "time": "2025-03-18T06:04:35Z"}, {"author": "Orie Steele", "text": "<p>Do you plan to register COAP Content Formats for your COSE / CWT related media types? <a href=\"https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats\">https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats</a></p>", "time": "2025-03-18T06:19:49Z"}, {"author": "Henk Birkholz", "text": "<p>+1 content-format, pls</p>", "time": "2025-03-18T06:23:03Z"}, {"author": "Pieter Kasselman", "text": "<p><span aria-label=\"wave\" class=\"emoji emoji-1f44b\" role=\"img\" title=\"wave\">:wave:</span></p>", "time": "2025-03-18T06:23:03Z"}, {"author": "Paul Bastian", "text": "<p>Draft for size comparison: <a href=\"https://drafts.oauth.net/draft-ietf-oauth-status-list/276-size-comparison/draft-ietf-oauth-status-list.html#name-size-comparison\">https://drafts.oauth.net/draft-ietf-oauth-status-list/276-size-comparison/draft-ietf-oauth-status-list.html#name-size-comparison</a></p>", "time": "2025-03-18T06:25:13Z"}, {"author": "Orie Steele", "text": "<p>I was waving at Filip : )</p>", "time": "2025-03-18T06:37:26Z"}, {"author": "Rifaat Shekh-Yusef", "text": "<p>Got it. Thanls!</p>", "time": "2025-03-18T06:37:43Z"}, {"author": "Filip Skokan", "text": "<p>Thanks Paul and Christian</p>", "time": "2025-03-18T06:46:46Z"}, {"author": "John Bradley", "text": "<p>We do have atleast one EUDI wallet that needs to do this running in JS in the browser</p>", "time": "2025-03-18T06:47:23Z"}, {"author": "Paul Bastian", "text": "<p>I know ;)</p>", "time": "2025-03-18T06:48:42Z"}, {"author": "John Bradley", "text": "<p>Just wanted to show I am not sleeping</p>", "time": "2025-03-18T06:49:33Z"}, {"author": "Paul Bastian", "text": "<p>Is CORS handlers squatting on the whole HTTP OPTIONS method? I thought it's kind of the first major use case but must not be the only one?</p>", "time": "2025-03-18T06:49:40Z"}, {"author": "Filip Skokan", "text": "<p>A good web application framework will discern between a preflight and a non-Preflight request and give the dev an option to handle the non-preflight.</p>\n<p>What this dance will do in a browser, since both the nonce-fetching and actual request is</p>\n<p>1) OPTIONS Preflight for the nonce-fetch<br>\n2) nonce-fetch<br>\n3) OPTIONS Preflight for the actual request<br>\n4) actual request</p>\n<p>The js client has no access to the preflight response so there's no option to make the preflight the nonce-value vessel. Of course at the point the actual request's preflight the nonce must be incorporated in the request.</p>", "time": "2025-03-18T06:55:26Z"}, {"author": "Filip Skokan", "text": "<p>(meetecho messed up the list formatting)</p>", "time": "2025-03-18T06:55:46Z"}, {"author": "Filip Skokan", "text": "<p>fix: since both the nonce-fetching and actual request * are not \"simple\" requests</p>", "time": "2025-03-18T06:57:51Z"}, {"author": "Filip Skokan", "text": "<p>see \"simple requests\" <a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests\">https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests</a></p>", "time": "2025-03-18T06:58:37Z"}, {"author": "Brian Campbell", "text": "<p>Filip's perspective here has me second guessing the original suggestion to use HEAD/OPTIONS. Sorry...</p>", "time": "2025-03-18T07:05:33Z"}, {"author": "Orie Steele", "text": "<p>^ yeah, I would like to understand what lead to that... I like the idea of discovering a get endpoint... feels similar to discovering jwks</p>", "time": "2025-03-18T07:07:10Z"}, {"author": "Tim Cappalli", "text": "<p>I'll do that by Madrid.</p>", "time": "2025-03-18T07:08:00Z"}, {"author": "Christian Bormann", "text": "<p>The discussion was between introducing a new endpoint and somehow using/overloading existing endpoints. I guess we should re-visit the introduction of a dedicated endpoint?</p>", "time": "2025-03-18T07:10:07Z"}, {"author": "Phillip Hallam-Baker", "text": "<p>I have only implemented PAR. Took me all of three days to implement the whole stack. Not sure why people would have issues with PAR</p>", "time": "2025-03-18T07:14:10Z"}, {"author": "George Fletcher", "text": "<p>I do think the requirements of the AS to verify the first-partiness of the client is something that may not be implemented correctly. Maybe this is true even if there is a separate endpoint but hopefully given the intent of the separate endpoint is to also explicitly only support first party apps makes it more likely to be implemented correctly.</p>", "time": "2025-03-18T07:17:23Z"}, {"author": "Brian Campbell", "text": "<p>have PAR and think this would make it more difficult to adopt</p>", "time": "2025-03-18T07:21:09Z"}, {"author": "Filip Skokan", "text": "<p>As an implementer - it's actually easier NOT to have it a PAR extension because all my \"authorization-like\" endpoints already reuse all of the pipeline.</p>", "time": "2025-03-18T07:21:11Z"}, {"author": "Filip Skokan", "text": "<p>(subjective)</p>", "time": "2025-03-18T07:21:53Z"}, {"author": "Brian Campbell", "text": "<p>Filip expresses my (subjective) thoughts better than I did</p>", "time": "2025-03-18T07:22:14Z"}, {"author": "Brian Campbell", "text": "<p>as he often does</p>", "time": "2025-03-18T07:22:21Z"}, {"author": "Justin Richer", "text": "<p>I agree with that :if: you already have PAR and :if: you want to build the most clean abstraction and maximize the re-use of pipelines. I don't think that that really holds.</p>", "time": "2025-03-18T07:27:22Z"}, {"author": "George Fletcher", "text": "<p>If we move toward extending PAR then I recommend to add a new parameter (or value for an existing parameter) that explicitly declares the behavior requested is that from OAuth for First Party Apps.</p>", "time": "2025-03-18T07:30:07Z"}, {"author": "Henk Birkholz", "text": "<p>Is this interpretation of a default scheme compliant with rfc7320?</p>", "time": "2025-03-18T07:35:42Z"}, {"author": "Joseph Heenan", "text": "<p>@henk it's not a URI. This isn't a URI scheme. (There is an argument for this draft to stop using the word 'scheme' because of this confusion.)</p>", "time": "2025-03-18T07:36:44Z"}, {"author": "Brian Campbell", "text": "<p>this is not a URI scheme</p>", "time": "2025-03-18T07:36:58Z"}, {"author": "Henk Birkholz", "text": "<p>Ah! It is not a uri! Got it. Thx</p>", "time": "2025-03-18T07:37:40Z"}, {"author": "Henk Birkholz", "text": "<p>I think this confused me: <a href=\"https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-scheme-01.html#name-defined-client-identifier-s\">https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-scheme-01.html#name-defined-client-identifier-s</a></p>", "time": "2025-03-18T07:41:10Z"}, {"author": "Henk Birkholz", "text": "<p>And talking about prefix and scheme and such, I agree</p>", "time": "2025-03-18T07:41:42Z"}, {"author": "David Waite", "text": "<p>The issue with them being URI is that the spec defining how to associate and secure metadata for an entity is AFAIK never by the party who \"owns\" that URI scheme.</p>", "time": "2025-03-18T07:49:45Z"}, {"author": "Aaron Parecki", "text": "<p>yeah we should probably rename it from \u201cscheme\u201d to \u201cprefix\u201d in the next update so it\u2019s clearer that it\u2019s not a URI</p>", "time": "2025-03-18T07:49:55Z"}, {"author": "Andy Barlow", "text": "<p>+1</p>", "time": "2025-03-18T07:50:14Z"}, {"author": "Tim W\u00fcrtele", "text": "<p>Multiple docs for one BCP: I think that's possible, at least from looking at the IETF documents around the BCP process</p>", "time": "2025-03-18T07:51:39Z"}, {"author": "Joseph Heenan", "text": "<p>What Brian says is true - BCP195 is currently two documents: <a href=\"https://www.rfc-editor.org/info/bcp195\">https://www.rfc-editor.org/info/bcp195</a></p>\n<p>Personally I find it a bit confusing...</p>", "time": "2025-03-18T07:51:42Z"}, {"author": "David Waite", "text": "<p>Even one of the special cases (did), the definition of how to resolve OAuth metadata does not live in W3C</p>", "time": "2025-03-18T07:51:47Z"}, {"author": "Alex Chalmers", "text": "<p>I love the idea of making the BCP a living collection of documents, rather than a monolithic document. Especially given the blast radius of OAuth across so many use cases, having an agile approach makes a lot of sense.</p>", "time": "2025-03-18T07:55:08Z"}, {"author": "Ira McDonald", "text": "<p>+1</p>", "time": "2025-03-18T07:55:26Z"}, {"author": "David Waite", "text": "<p>a fellow from GitHub said while describing their continuous deployment model \"if something is painful, you aren't doing it often enough\"</p>", "time": "2025-03-18T07:56:31Z"}, {"author": "Alex Chalmers", "text": "<p>Perhaps the only suggestion I would make to that is potentially having a guidepost type RFC that helps contextualize all the documents within the BCP.</p>", "time": "2025-03-18T07:56:39Z"}, {"author": "Justin Richer", "text": "<p>BCP is intentionally defined as a living reference whose contents can be udpated</p>", "time": "2025-03-18T07:57:09Z"}, {"author": "Tim W\u00fcrtele", "text": "<p>Yes, thank you very much for the input on the process!</p>", "time": "2025-03-18T07:58:22Z"}, {"author": "Alex Chalmers", "text": "<p>Absolutely agree, Justin.  My comment was really just agreeing with your point of leveraging that exact facility of the BCP series.</p>", "time": "2025-03-18T07:59:19Z"}]