[Openid-specs-ab] Issue #856: Discovery - URI grammar definition doesn't allow acct: scheme (openid/connect)
Mike Jones
Michael.Jones at microsoft.com
Sat Jun 29 17:17:01 UTC 2013
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<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-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130629/832a564e/attachment.html>
More information about the Openid-specs-ab
mailing list