What if callerOrigin is an opaque origin

[annevk]

You can't get a public suffix out of that.

[annevk]

In particular, you can only determine that if the origin has a host and the host is not an IP address of some kind.

[annevk]

(See the WHATWG HTML Standard for the actual terms you need to use here.)

[equalsJeffH]

i believe @annevk is referring to: https://html.spec.whatwg.org/multipage/browsers.html#origin

[balfanz]

@annevk - can you explain what the problem would be? Is there something in the spec that wouldn't work for opaque origins?

[annevk]

Yes, see OP.

[equalsJeffH]

this issue is closely related to #171 and will be addressed as part of addressing the latter.

[vijaybh]

I would propose that we do not handle such cases for now. For v1 I would focus on the core use case of an interactive user in an active browsing context.

[annevk]

You need to handle it somehow. You can't just leave things undefined (or in this case, cause a segfault).

[rlin1]

see https://www.w3.org/TR/html51/browsers.html#opaque-origin for definition of opaque origin.

[annevk]

You really want to be using https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque as a reference at all times. The copy-and-pasters of that work [HTML51] don't always do a good job.

[rlin1]

In what situations would such opaque origins appear?
https://html.spec.whatwg.org/multipage/browsers.html#creator-browsing-context says:
A browsing context can have a creator browsing context, the browsing context that was responsible for its creation. If a browsing context has a parent browsing context, then that is its creator browsing context. Otherwise, if the browsing context has an opener browsing context, then that is its creator browsing context. Otherwise, the browsing context has no creator browsing context.

[annevk]

Data URLs and sandboxing, at least.

[rlin1]

I see two potential approaches to deal with such situation:

Approach 1:
Some JavaScript without a clear association of a creator browsing context could be seen as using the Browser as an "App".

Remember: outside the web use case, Apps can also create such scoped authentication credentials. But instead of scoping the credential to some web server the App might be talking to, we scope the credential to the App itself.

A web browser apparently can act on behalf of some RP identified by a non-opaque origin, or it could act as an App, i.e. within the scope of a browser vendor.

Approach 2:
Such opaque origin will never be equal to any other opaque-origin. Consequently, it seems impossible at any later point in time to access things which have been scoped to such Opaque Origin.
Persistently stored credentials scoped to such Opaque Origin could never be re-used at a later point (i.e. after this opaque-origin is gone).
Why would someone want to do that? So we might argue there is no point in supporting that and makeCredential would just fail.

Opinions?

[annevk]

I think you should just make it fail, fwiw.

[vijaybh]

Clarifying my earlier comment - this is what I was trying to say too. By "not handle it" I meant "treat it as a failure case and don't worry about it, if there is a legitimate need for it someone will come along to tell us soon enough".

[equalsJeffH]

Yes, approach 2, am crafting spec text to that end.