[Openid-specs-ab] Issue #856: Discovery - URI grammar definition doesn't allow acct: scheme (openid/connect)

Nat Sakimura sakimura at gmail.com
Mon Jul 1 15:13:37 UTC 2013


Right, we normalized to https:// when a user just typed user at host and that
was a quite deliberate thing I did. It was not just left off from SWD day.
We had plenty of days to review it, and I did. There were several reasons:

   1. I was not certain of what will become of acct: uri. I am still
   concerned that some Cool URI people may ring in at the very end and
   jeopardize;
   2. Minimal impact to the existing codes;
   3. Easy for the code: they can use conventional URI parser to extract
   userinfo, host, and port.
   4. There is nothing wrong with using https:// instead of acct: as far as
   Webfinger is concerned.

True, the Webfinger has in its non-normative example, acct: uri example for
OpenID Connect. However, that is just an example. When we went to
implementer's draft review period, we had a normative text around https://,
which has no problem on our part. Switch from acct: to https:// is not an
editorial errata. It is a technical change and should not be dealt with
lightly from the process point of view.

Also, I cannot find the ticket which is associated with the change set
20ebf04<https://bitbucket.org/openid/connect/commits/20ebf0461dea1daa76d63aeb824fb36dd79fd2f2>,
which is a normative change after the start of the review period. Is there
one? If not, we need to create it.

Nat


2013/7/1 John Bradley <ve7jtb at ve7jtb.com>

> The problem with normalizing "user at host" to "https:user at host"  is mostly
> that simple WF servers may only match on the acct: form it seems to be the
> recommended thing to normalize input to.
>
> Before we made the last change in normalization rules to support "acct:"
>  all input without a scheme was normalized to "https:" ,  even if we backed
> that out we would still need to still need a rule to support
> non-higher-archical URI like "acct:".
>
> The bottom line is if someone types "user at host"  we should have one way
> of converting that to a URI for WF, otherwise we are headed for
> interoperability issues.
>
> We also need to think about what we do for RFC3541 "tel:" as it is also
> not higher-archical, though likely it will need some sort of meta-data
> service/proxy to be useful.
>
> John B.
>
>
> On 2013-06-29, at 9:16 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> Actually, I and John discussed this issue over Skype last night and John's
> response was the result of it. So my comments are included in his response.
>
> BTW, what is the value in normalizing to acct scheme? To me, https seems
> perfectly fine, and would not cause the problems that Justin is getting.
>
> =nat via iPhone
>
> Jun 30, 2013 2:17、Mike Jones <Michael.Jones at microsoft.com> のメッセージ:
>
> Can you work on a concrete proposal to apply as errata, John?  And Nat,
> once you’re able to think critically, maybe you could work on this as well?
>
>
>                                                             Thanks both,
>
>                                                             -- Mike
>
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com>]
> *Sent:* Saturday, June 29, 2013 9:19 AM
> *To:* Mike Jones
> *Cc:* Justin Richer; openid-specs-ab at lists.openid.net List; Peter
> Saint-Andre
> *Subject:* Re: [Openid-specs-ab] Issue #856: Discovery - URI grammar
> definition doesn't allow acct: scheme (openid/connect)
>
>
> I think part of our problem is that in RFC3986 "host" is part of authority
> and authority is part of higher-part which begins with "//".
>
>
> The "mailto" scheme stuffs everything into path so doesn't have and
> authority owing to dealing with multiple recipients (it is a complex
> scheme) .
>
>
> If "acct" was using higher-part rather than path it would simplify our job
> trying to normalize the various sorts of inputs for discovery.
>
>
> The "acct" scheme uses  ":"  userpart "@" host  (It defines userpart
> rather than re using userinfo).  While being unusual having host in a path,
> I am guessing it is just the ABNF, so is a different host from the one in
> higher-part.
>
>
> I don't think the below works for generic URI without a higher-part so we
> would be better  saying  or "acct" ":" userpart "@" host.
>
>
> That leaves out the mailto uri but processing rules to generically pick
> that apart are a real challenge, and would need to be restricted to a
> single recipient with no headers etc so would need it's own section for
> that scheme specifically if we want to support it.
>
>
> There is also a problem with differentiating foo.org:8080 as that could
> be interpreted as a scheme or foo.org with a path of 8080 so being
> explicit about what schemes without higher-part are supported may be a good
> idea.
>
>
> John B.
>
>
> On 2013-06-29, at 7:20 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>
>
>
>  I'd add another "or" to prevent confusion as below, but otherwise I
> agree with this change.  Do others?
>
>
> a URI in the form of scheme "://" authority path-abempty [ "?" query ] [
> "#" fragment ] or authority path-abempty [ "?" query ] [ "#" fragment ] or
> scheme ":" userinfo "@" host per RFC 3986 [RFC3986]
>
>
>
> -- Mike
>
>
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-
> specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
> Sent: Friday, June 28, 2013 6:55 AM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Issue #856: Discovery - URI grammar definition
> doesn't allow acct: scheme (openid/connect)
>
>
> New issue 856: Discovery - URI grammar definition doesn't allow acct:
> scheme
> https://bitbucket.org/openid/connect/issue/856/discovery-uri-grammar-definition-doesnt
>
>
> Justin Richer:
>
>
> The instructions as written in 2.1.1/2.1.2 don't actually allow for the
> acct: URI scheme. The acct: scheme is a non-heirarchical URI, which means
> it doesn't include the "//" component, and the text currently states:
>
>
> ```
>
>     a URI either in the form of scheme "://" authority path-abempty [ "?"
> query ] [ "#" fragment ] or authority path-abempty [ "?" query ] [ "#"
> fragment ] per RFC 3986 [RFC3986].
>
> ```
>
>
> I think this needs an errata published as the intent was more like:
>
>
> ```
>
>     a URI in the form of scheme "://" authority path-abempty [ "?" query ]
> [ "#" fragment ], authority path-abempty [ "?" query ] [ "#" fragment ],
> **or scheme ":" userinfo "@" host** per RFC 3986 [RFC3986].
>
> ```
>
>
>
>
>
> _______________________________________________
>
> Openid-specs-ab mailing list
>
> Openid-specs-ab at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130702/b93c1f8e/attachment-0001.html>


More information about the Openid-specs-ab mailing list