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

Issue #676 resolved
Michael Jones created an issue

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)

  1. John Bradley

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

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

  3. Michael Jones 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.

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

  5. Log in to comment