Closed sbweeden closed 5 months ago
Sorry, I got a bit delayed with the blog post and all the activity here. Should be ready by next week. I have updated the timeline, it should not affect the next milestone as I'm not working on that.
BTW, it would not work anyway as in the current form the challenge needs to be a byte string, but I will update that after landing the registration.
I noticed you change the milestone to Chrome 126 for the registration example, but didn't change the flag names? Also I now I have Chrome Canary 126, and modified my server to return:
Sec-Session-Registration: "/securesession";es256;challenge=:Y2hhbGxlbmdl:
but still don't see any activity from the browser.
Is there anything actually ready to test against, and can you please provide an example of a captured working execution of the flow, plus any debugging tips, as there is nothing displayed in the browser console either.
The branch point for 126 is 13th of May, so it will be there before that. I hope next week, I'll post back on this post once it has landed.
I have a test server at https://decisive-malleable-snagglefoot.glitch.me/ that I keep up to date as headers change etc.
The flag to use is chrome://flags/#enable-standard-device-bound-session-credentials, I'll write up a page on how to test it when it has landed.
Say, what encoding is used on the challenge
query parameter to get bytes to ":Y2hhbGxlbmdl:
" format?
https://www.rfc-editor.org/rfc/rfc8941.html#section-3.3.5 base64 :Y2hhbGxlbmdl: <-> challenge
Sorry if I'm repeating something that's already been asked, but is there a way to test this? For example, can we set up a local environment with a framework of our choice?
https://www.rfc-editor.org/rfc/rfc8941.html#section-3.3.5 base64 :Y2hhbGxlbmdl: <-> challenge
Can we please change this format to base64url encoding, with no start/end colons. Just plain base64url encoding, same as is used in JWT segments would be preferred, and is already widely used. Using a byte sequence would mean that padding chars would have to be %-encoded in a URL, and base64url encoding is already URL safe.
Hey it will be updated to a string with no encoding, or at least no encoding that the browser care about. It will put whatever string it receives in the JWT.
See discussion here: https://github.com/WICG/dbsc/issues/45
Sorry, I got a medical emergency so was out for a while. I wrote up a short section on the wiki on how to try out early versions of DBSC: https://github.com/WICG/dbsc/wiki/Testing-early-versions-of-DBSC
I've read the estimated timeline, and looked at the flags available in Chrome Canary 125 on Mac. These don't line up - the estimated timeline suggests a flag called
#enable-standard-device-bound-session-credentials
whereas in Chrome Canary I have two different flags that seem related, neither of them with this name:#enable-bound-session-credentials-software-keys-for-manual-testing
#enable-bound-session-credentials
Further, I enabled both these, then setup a URL on a web server that returned the HTTP header:
Upon accessing this URL I can see the response header in the Network debugger on the browser, but the browser never makes a request to /securesession/startsession
So ... can the milestones document please be updated, and can someone help with providing a pointer to where I can tell what actually is supposed to work at this point?