The 'acct' URI Scheme
RFC 7565

Note: This ballot was opened for revision 03 and is now closed.

(Richard Barnes) (was Discuss, Yes) Yes

Comment (2013-03-25 for -04)
No email
send info
The word "discussants" may not be familiar to some readers.  "Participants in the discussion" might be a little clearer.


"""
 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 associated with a user’s account
 at a service.
"""

Alongside "authentication and authorization", it might be good to call out "confidentiality" as well.

Barry Leiba Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

Comment (2013-03-27 for -03)
No email
send info
I have no objection to the publication of this document. I have one small
observation that those with more clue than I might consider.

It is probably a trivial concern, but isn't it the case that where
previously the knowledge of access to an http scheme did not mean that
I could guess the access to a mailto scheme, the use of a common 'acct'
scheme removes a level of guesswork. While such obfuscation of access
information can hardly be considered strong security, it did offer a
tiny bit of additional security that is now removed.

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-05-02 for -04)
No email
send info
Thanks for addressing my discuss point and comments.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) (was Discuss) No Objection

Comment (2013-03-28 for -03)
No email
send info
Clearing this as a DISCUSS; Pete will carry the standard for this, but here are my DISCUSS comments:

I'm concerned that this appears to be a URN, not just any old URI, and (I think!) we expect URNs to uniquely identify things.   But these identifiers really don't uniquely identify things—mellon@fugue.com, mellon@toccata.fugue.com, etc, are all in some sense the same identifier, even though the host part varies.   Also, mellon@204.152.186.142 definitely identifies the exact same user as mellon@toccata.fugue.com.

So this seems like neither a URL nor a URN.   Really it's just a string with some syntax; why does it need to be a URI?

(Pete Resnick) (was Discuss) No Objection

Comment (2013-06-21 for -05)
No email
send info
OK, this is exactly the right direction. I think if you make two more edits, it will be just fine.

Section 4:

   Instead, an 'acct' URI is employed indirectly and typically is passed
   around as a parameter in the background within a protocol flow so
   that an entity can interact with a resource related to that
   identified by the 'acct' URI in a particular way or for a particular
   purpose.  For example, in the WebFinger protocol
   [I-D.ietf-appsawg-webfinger] an 'acct' URI is used to identify the
   resource about which an entity would like to discover metadata
   expressed as "web links" [RFC5988]; the relevant HTTP request passes
   an 'acct' URI (or some other URI) as the value of a "resource"
   parameter, as shown in the following example:

   GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1

Please strike the above paragraph. (I've moved the example; see below.) Though it is true that the 'acct' URI will be passed around as a parameter in WebFinger, I think the "Instead" is bogus. WebFinger (in combination with whatever protocol will use the WebFinger framework) *will* have to know how to resolve the URI in order to find the server it's going to talk to, even if that's not a full "dereference". And a plausible non-WebFinger use of an 'acct' URI will involve no indirect or passed around use, but rather a full de-reference (i.e., taking the RHS, looking it up, connecting, and passing only the LHS without the scheme). WebFinger is a use case (and can be reasonably mentioned in the next paragraph), but the design of 'acct' URI does not depend on WebFinger's model of use.

                As a concrete example, in the WebFinger protocol an
   'acct' URI is passed as a parameter in an HTTP request for metadata
   (i.e., web links) about the resource; the service retrieves the
   metadata associated with the account identified by that URI and then
   provides that metadata to the requesting entity in an HTTP response
   (see [I-D.ietf-appsawg-webfinger] for details).

If you're going to use WebFinger as an example, let's be a bit more precise:

   As a concrete example, an "Account Information" application of the
   WebFinger protocol [I-D.ietf-appsawg-webfinger] might take an 'acct'
   URI, resolve the host portion to find a WebFinger server, and then
   pass the 'acct' URI as a parameter in a WebFinger HTTP request for
   metadata (i.e., web links [RFC5988]) about the resource. For example:

   GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1

   The service retrieves the metadata associated with the account
   identified by that URI and then provides that metadata to the
   requesting entity in an HTTP response.

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-05-09 for -04)
No email
send info
Cleared my discuss based on the publication of draft-saintandre-username-interop-00.