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

[Peter Saint-Andre <[e-mail]>]

On 7/1/12 7:30 AM, Barry Leiba wrote:
>>> 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.

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

> 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).

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

> 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.

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. :)

>    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. 

I share your concern.

> 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.

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/