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

Nat Sakimura sakimura at gmail.com
Tue Jul 2 02:22:54 UTC 2013


I agree with allowing acct: etc. grammatically though it is not so simple.

As a chair of the WG, I have objection on changing the normative
normalization rule because of the process reason. If it were to happen, it
should have happened before the Public Review Period. The reason like "we
intended to be, and examples are showing ... " is not acceptable. We are
creating a standard, and normative language is everything. Just changing
normative language technically after the freeze announcement will put the
integrity of the process in question.

We could deal with technical changes in the comment resolution meetings,
but we should not make on-the-fly changes.

Note: this does not prevent interop participants to do the acct:
normalization "experiments".
I expect that is going to be harder than https:// normalization though
because you have to hand code the host part extraction by yourself and
that's actually error prone.



2013/7/2 Justin Richer <jricher at mitre.org>

>  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 <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>****
>
> 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> 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>****
>
> The problem with normalizing "user at host" to "https:user at host"<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****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://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/a93f16c7/attachment-0001.html>


More information about the Openid-specs-ab mailing list