Discovery 2.1.2 - Allow port number to be specified for e-mail syntax identifiers
For OpenID Connect identifier normalization, I would propose that we allow port numbers on e-mail-syntax identifiers. For instance, we should accept ve7jtb@ve7jtb.com:8888 to say that discovery for the identifier ve7jtb@ve7jtb.com is to be performed on the discovery server at port 8888.
That's a different thing than whether acct: needs to allow port numbers. I could discover acct:ve7jtb@ve7jtb.com at the port 8888 discovery server based upon the user input ve7jtb@ve7jtb.com:8888 without incurring any interoperability issues.
Comments (8)
-
-
reporter -
assigned issue to
Nat will verify that it's clear that people need to implement this functionality.
-
assigned issue to
-
Actually, I mis-spoke in the previous call.
URI in RFC 3986 is defined as follows:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) authority = [ userinfo "@" ] host [ ":" port ]
URI Relative reference is as follows:
relative-ref = relative-part [ "?" query ] [ "#" fragment ] relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty path = path-abempty ; begins with "/" or is empty / path-absolute ; begins with "/" but not "//" / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
Therefore, we cannot allow the user input in the form of "user@host:port"
If the port is for the testing purpose, then the test user should input "//user@host:port" instead of "user@host:port".
-
reporter OK - can you describe the "//user@host:port syntax in the spec then -- probably in the same place we talk about using the port number for the SWD endpoint? It would be fine to say that it's for debugging purposes.
-
With a closer reader, it was actually much more complex.
To include authority in URI relative reference, it had to have "//" in it. Thus, we just cannot say that "All other user input Identifiers MUST be treated as URI relative references." in Section 2.1.1.
So, the bug that was pointed out by @lef, which has been closed by my edit, was actually not dealt with.
I will reopen the bug.
-
Actually, fix for
#625now allows user@host:port syntax. -
- changed status to open
-
- changed status to resolved
- Log in to comment
That is probably a reasonable compromise though we probably want to agree on a normalization pattern across the underlaying mechanism.