Subject: [apps-discuss] The acct: scheme definition -- draft-saintandre-acct-uri

From: Barry Leiba <[email-masked]>
Date: Sun, 1 Jul 2012 09:30:00 -0400

>> Graham, I think you're right about the fact that these matters are
>> underspecified. I hereby offer to propose some text, and will do that in
>> the next few days.
>
> I went beyond proposing text and decided to write a standalone I-D:
>
> http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/
>
> Graham, I think that text answers the questions you posed, hopefully in
> an accurate way.

I have a couple/few comments.

Very tiny minor: I might like to see informative references for mailto
[RFC6068] and http (probably [RFC2616], so this isn't waiting on the
httpbis set).

Slightly less tiny: The Security Considerations are correct, as far as
this goes, about the existence of an acct: URI.  Only, this spec
provides no way to expose or test the existence of an acct: URI, so it
does not expose the security issue you're noting.  I'm not sure what
the right change is to this document's Security Considerations for
that, but I really don't see how the creation of this scheme, without
another document's definition of how it can actually be used, poses
any security issue at all.

Significantly less tiny, indeed; issues about the grammar:

   domainpart   =  domainlabel 1*( "." domainlabel)
   domainlabel  =  alphanum / alphanum *( alphanum / "-" ) alphanum

First, to avoid ambiguity, please either

   domainlabel  =  alphanum / (alphanum *( alphanum / "-" ) alphanum)

...or, better,

   domainlabel  =  alphanum  [ *( alphanum / "-" ) alphanum ]

Second, and more important, it concerns me that we have so many
varying definitions of the same entity, a domain name.  Yours is a
variant of what's in RFC 5321 (SMTP) -- a variant, not a reference nor
a copy, though "domainlabel" here specifies exactly the same thing as
"sub-domain" in 5321:

   Domain       = sub-domain *("." sub-domain)
   sub-domain   = Let-dig [Ldh-str]
   Let-dig      = ALPHA / DIGIT
   Ldh-str      = *( ALPHA / DIGIT / "-" ) Let-dig

We have this, from RFC 3986 (URIs):

   host        = IP-literal / IPv4address / reg-name
   reg-name    = *( unreserved / pct-encoded / sub-delims )

We have this, from RFC 6068 (mailto):

   domain       = dot-atom-text / "[" *dtext-no-obs "]"

And those are just in the documents you're citing.  Others surely
exist in other places.  I don't like adding one more to the set of
different definitions.  I suggest instead that you either use this:

   domainpart   =  sub-domain 1*( "." sub-domain)
                ; sub-domain is defined in SMTP [RFC5321]

...if you really want to keep the change that a domain has to have at
least two parts, or this:

   domainpart   =  Domain
                ; Domain is defined in SMTP [RFC5321]

...if you're willing to accept that a domain can have just one part.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 02 Jul 2012 10:16:40 -0600

> I have a couple/few comments.

With or without your area director hat on? ;-)

> [RFC6068] and http (probably [RFC2616], so this isn't waiting on the

Well, it wouldn't wait on the httpbis set if the reference were
informational, but I agree that citations would be good.

> any security issue at all.

If a URI scheme is defined in a specification but isn't used by any
protocol, does it introduce a security concern?

Perhaps it would be best for this document to describe what
specifications of using protocols need to explain in their security
considerations sections.

Thus I suggest:

   Because the 'acct' URI scheme does not directly enable interaction
   with a user's account at a service provider, possible security
   concerns are minimized.

   Protocols that make use of 'acct' URIs are responsible for defining
   security considerations related to such usage, e.g., the risks
   involved in dereferencing an 'acct' URI and the authentication and
   authorization methods that could be used to control access to
   personally identifying information.

> Significantly less tiny, indeed; issues about the grammar:

That's the one part of draft-jones-appsawg-webfinger I copied over as-is. :)

> varying definitions of the same entity, a domain name. 

I share your concern.

> Yours is a

I would prefer to borrow the definition from RFC 3986 here, not tie this
spec to SMTP or mailto definitions.

Thus:

   The 'acct' URI syntax is defined here in Augmented Backus-Naur Form
   (ABNF) [RFC5234], borrowing the 'unreserved' and 'pct-encoded' rules
   from that specification and the 'host' rule from [RFC3986]:

   acctURI      =  "acct:" userpart "@" host
   userpart     =  1*( unreserved / pct-encoded )

We could even borrow the 'userinfo' rule from RFC 3986:

   userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )

I think there's good reason to exclude the user:password format in
userinfo, as mentioned in RFC 3986. But what about sub-delims? Perhaps
this is more appropriate:

   userpart    = 1*( unreserved / pct-encoded / sub-delims )

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Jul 2012 12:57:49 +0900

>     userpart    = 1*( unreserved / pct-encoded / sub-delims )

Fully agreed.    Regards,   Martin.