The 'acct' URI Scheme
draft-ietf-appsawg-acct-uri-07
Yes
(Barry Leiba)
No Objection
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Stewart Bryant)
Note: This ballot was opened for revision 03 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -03)
Unknown
Richard Barnes Former IESG member
(was Discuss, Yes)
Yes
Yes
(2013-03-25 for -04)
Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-03-27 for -03)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2013-06-21 for -05)
Unknown
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.
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-05-09 for -04)
Unknown
Cleared my discuss based on the publication of draft-saintandre-username-interop-00.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-05-02 for -04)
Unknown
Thanks for addressing my discuss point and comments.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ted Lemon Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-28 for -03)
Unknown
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?