Discovery 2.1.2 - Allow port number to be specified for e-mail syntax identifiers

[Michael Jones]

For OpenID Connect identifier normalization, I would propose that we allow port numbers on e-mail-syntax identifiers. For instance, we should accept [e-mail]:8888 to say that discovery for the identifier [e-mail] 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:[e-mail] at the port 8888 discovery server based upon the user input [e-mail]:8888 without incurring any interoperability issues.

[John Bradley]

That is probably a reasonable compromise though we probably want to agree on a normalization pattern across the underlaying mechanism.

[Michael Jones]

Nat will verify that it's clear that people need to implement this functionality.

[Nat Sakimura]

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".

[Michael Jones]

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.

[Nat Sakimura]

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.

[Nat Sakimura]

Actually, fix for #625 now allows user@host:port syntax.

[Nat Sakimura]

11d4f15