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

Mike Jones Michael.Jones at microsoft.com
Wed Jul 3 15:37:19 UTC 2013


I’d previously sent the reply below to Nat and we just discussed it on the phone.  We agreed that I should send it to the list so everyone can easily follow the changes if they’d like to.

                                                            -- Mike

Hi Nat,

You’d asked about the history of the discovery normalization rules on the call.  Here’s what I see from the change logs and call notes.

Your new normative language for normalization was added in https://bitbucket.org/openid/connect/commits/2d37bc2d8f45/ on 2012-09-13 (as referenced from https://bitbucket.org/openid/connect/issue/622/discovery-212-domain-literal-and-cfws).  Then as described in https://bitbucket.org/openid/connect/issue/625/discovery-223-examplecom-8080-has-a-scheme, it was tweaked on 2012-12-11 in https://bitbucket.org/openid/connect/commits/599c79468b26 and https://bitbucket.org/openid/connect/commits/aedbb5f/.  At that time, we were still using SWD.

We switched to using WebFinger and acct: on 2013-01-22 as described in https://bitbucket.org/openid/connect/issue/576/discovery-monitor-ietf-discovery-spec and https://bitbucket.org/openid/connect/issue/705/move-discovery-from-swd-to-webfinger in edit https://bitbucket.org/openid/connect/commits/d206e8b26e5f following the decision made on the 21-Jan-13 call.  The intent of that decision is recorded in the call notes as “Doing this now will avoid the need for breaking changes later” and in the issue tracker for #705 as “This will allow us to not knowingly have any upcoming breaking changes after the implementer's drafts”.  The change log for this edit also included “This also means that Identifiers using e-mail address syntax are prefixed by the “acct:” scheme when passed as “resource” parameters to WebFinger.” So our intent was clearly recorded.

I take responsibility for not recognizing that we needed a grammar change when we switched to WebFinger and acct:.  That’s unfortunate but true.  I’m glad that Justin caught it, resulting in issue https://bitbucket.org/openid/connect/issue/856/discovery-uri-grammar-definition-doesnt.  For the spec to be internally consistent, we need the grammar change.  We decided on yesterday’s call to make it, as recorded both in the call minutes and in the issue tracker.  For all these reasons, I believe we need to make the change.

The first errata change that the working group decided to make changed the normative text - specifically, the normalization steps in 2.1.2, as seen in https://bitbucket.org/openid/connect/commits/20ebf0461dea1daa76d63aeb824fb36dd79fd2f2 and https://bitbucket.org/openid/connect/commits/deba9bdd1c4b59bf4d6149b102a4523aac53978d.  We told people that and no one objected.  The fix to #856 is no more invasive that that, so I don’t see why people would object to it any more than the first released errata fix.

I agree with you that we need to be transparent and mindful of process.  That means we have to notify the working group that anyone has the right to restart the 45 day clock, just as we’ve done for the other errata releases.  I hope no one will restart the clock - including you.  But I respect anyone’s right to do so.

                                                                Best wishes,
                                                                -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Monday, July 01, 2013 7:23 PM
To: Justin Richer
Cc: Mike Jones; John Bradley; 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 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<mailto: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]
Sent: Monday, July 01, 2013 9:47 AM
To: John Bradley
Cc: Mike Jones; 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)

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"<https://user@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<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130703/7f0ba21e/attachment-0001.html>


More information about the Openid-specs-ab mailing list