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

John Bradley ve7jtb at ve7jtb.com
Mon Jul 1 15:37:28 UTC 2013


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: 
> 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; 
> Minimal impact to the existing codes;
> Easy for the code: they can use conventional URI parser to extract userinfo, host, and port. 
> 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, 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] 
>>> 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: 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
>>> 
>>> 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/20130701/19efb9e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130701/19efb9e5/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list