This repository has been archived by the owner on Jul 30, 2019. It is now read-only.
Consider refactoring the document.domain attribute setter as a standalone algorithm #769
Comments
|
I suspect it'll work to start the extracted algorithm at approximately step 4, and pass the Beyond that, I'd suggest you write the patch against https://github.com/whatwg/html instead of this repository, so that you're starting from a correct version of the algorithm (see #793). |
|
Okay, will do @jyasskin - thanks. Should I re-open a similar (and linking) issue over at whatwg? |
|
It wouldn't hurt to have a separate issue in whatwg's repo, but I think you can get away with a raw PR that refers to this issue. |
jcjones
added a commit
to jcjones/html
that referenced
this issue
Feb 17, 2017
This is in response to W3C/HTML PR whatwg#769 (w3c/html#769). The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the document.domain attribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com. However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments. We had started some work to inline the procedure as an algorithim within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
jcjones
added a commit
to jcjones/html
that referenced
this issue
Feb 17, 2017
This is in response to W3C/HTML PR whatwg#769 (w3c/html#769). The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the document.domain attribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com. However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments. We had started some work to inline the procedure as an algorithim within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
jcjones
added a commit
to jcjones/html
that referenced
this issue
Feb 17, 2017
This is in response to W3C/HTML PR w3c/html#769. The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the document.domain attribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com. However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments. We had started some work to inline the procedure as an algorithim within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
jcjones
added a commit
to jcjones/html
that referenced
this issue
Feb 17, 2017
This is in response to W3C/HTML PR w3c/html#769. The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the document.domain attribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com. However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments. We had started some work to inline the procedure as an algorithm within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
jcjones
added a commit
to jcjones/html
that referenced
this issue
Feb 17, 2017
This is in response to W3C/HTML PR w3c/html#769. The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the document.domain attribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com. However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments. We had started some work to inline the procedure as an algorithm within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
|
this should be closed now that PR #2365 landed? |
|
Sounds right. Thanks for the reminder! |
|
We should keep this open to track merging whatwg/html#2365 into HTML5.2. It doesn't block WebAuthn anymore, but the W3C editors still have a bit of work to do. |
|
This issue tracker is for W3C's spec, so the issue is still open. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The Web Authentication WG's draft currently makes reference to the "Relaxing the same-origin restriction" of the
document.domainattribute setter as a way to let relying parties use foo.bar.com to generate scoped credentials for bar.com.However, 1) the attribute setter procedure isn't documented as an algorithm - so we shouldn't call it like one, and 2) we need to override some of the ambient state within it, by changing some of the values to be passed as arguments.
We had started some work to inline the procedure as an algorithim within our document, but consensus is that it'd be better if we could avoid future divergence by refactoring this part of the HTML spec instead.
I'm not an expert on HTML, but as a starting point, it seems we'd want to take the existing
document.domainattribute setter and make these adjustments:I'm happy to start a PR for these changes if this is acceptable.
The text was updated successfully, but these errors were encountered: