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

Justin Richer jricher at mitre.org
Mon Jul 1 17:12:40 UTC 2013


Agree with Mike -- I think the best bet would be that the grammar simply 
allow all of the examples given in the document.

  -- Justin

On 07/01/2013 12:49 PM, Mike Jones wrote:
>
> I agree that we should apply errata to have the grammar match the 
> examples.  Let's agree on specific wording on today's call in 6 hours.
>
> I would be strongly against normalizing everything to https: because 
> that would be an unnecessary breaking change.
>
> -- Mike
>
> *From:*Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Monday, July 01, 2013 9:47 AM
> *To:* John Bradley
> *Cc:* Mike Jones; 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)
>
> Agreed, and there, Cool URI people would say: everything should 
> normalized to https:// !
>
> I am ok with the errata that will allow acct: and mailto:, tel: etc. 
> to be dealt with.
>
> Normatively changing the normalization rule from adding https:// to 
> acct: is probably not given it did not make into before the public 
> review period and sticking to https:// has values such as less 
> susceptibility towards the change.
>
> 2013/7/2 John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>
> It was discussed on the June 17 call and Mike asked me to write up a 
> Errata to have the normative text match the examples showing acct:.
>
> In the original you are correct user at host was normalized to https:// 
> and it was not legal in the normalization rules to have acct:user at host 
> as user input.
>
> As a side note we are also missing normalization to the tel: uri for 
> strings beginning with + (that can be added later)
>
> If we revert back to normalizing to https:// then the examples need to 
> change to match.
>
> I am not emotionally attached to "acct:" but I thought we were fully 
> adopting WF in this draft, and that implies normalizing things to 
> "acct:" though that is a touch vague as has been pointed out in there 
> review.    If every protocol picks a different scheme to normalize the 
> resource URI to that will cause problems for WF deployment.
>
> John B.
>
> On 2013-07-01, at 11:13 AM, Nat Sakimura <sakimura at gmail.com 
> <mailto:sakimura at gmail.com>> wrote:
>
>
>
> 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 <mailto: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 
> <mailto: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 
> <mailto: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]
>     *Sent:* Saturday, June 29, 2013 9:19 AM
>     *To:* Mike Jones
>     *Cc:* Justin Richer; openid-specs-ab at lists.openid.net
>     <mailto: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
>     <http://foo.org/>:8080 as that could be interpreted as a scheme or
>     foo.org <http://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
>     <mailto: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> [mailto:openid-
>     <mailto:openid->specs-ab-bounces at lists.openid.net
>     <mailto: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
>     <mailto: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:
>     schemehttps://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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>
>
>
> -- 
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130701/941ba00c/attachment-0001.html>


More information about the Openid-specs-ab mailing list