Skip to main content

The 'acct' URI Scheme
draft-ietf-appsawg-acct-uri-07

Revision differences

Document history

Date Rev. By Action
2015-05-13
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-05-12
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-05-07
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-05-07
07 (System) RFC Editor state changed to EDIT from MISSREF
2015-04-10
07 (System) RFC Editor state changed to MISSREF from REF
2015-04-03
07 (System) RFC Editor state changed to REF from EDIT
2015-02-23
07 (System) RFC Editor state changed to EDIT from MISSREF
2014-08-12
07 Barry Leiba Changed consensus to Yes from Unknown
2014-01-23
07 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-07.txt
2013-07-13
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-07-12
06 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-07-12
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-07-10
06 (System) IANA Action state changed to In Progress
2013-07-10
06 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-07-10
06 (System) RFC Editor state changed to MISSREF
2013-07-10
06 (System) Announcement was received by RFC Editor
2013-07-10
06 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-07-10
06 Amy Vezza IESG has approved the document
2013-07-10
06 Amy Vezza Closed "Approve" ballot
2013-07-10
06 Amy Vezza Ballot approval text was generated
2013-07-10
06 Barry Leiba State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-07-02
06 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-06.txt
2013-06-21
05 Pete Resnick
[Ballot comment]
OK, this is exactly the right direction. I think if you make two more edits, it will be just fine.

Section 4:

  …
[Ballot comment]
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.
2013-06-21
05 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2013-06-17
05 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-05.txt
2013-05-09
04 Sean Turner [Ballot comment]
Cleared my discuss based on the publication of draft-saintandre-username-interop-00.
2013-05-09
04 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-05-06
04 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss
2013-05-02
04 Stephen Farrell [Ballot comment]

Thanks for addressing my discuss point and comments.
2013-05-02
04 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-05-01
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-05-01
04 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-04.txt
2013-03-28
03 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-03-28
03 Ted Lemon
[Ballot comment]
Clearing this as a DISCUSS; Pete will carry the standard for this, but here are my DISCUSS comments:

I'm concerned that this appears …
[Ballot comment]
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?
2013-03-28
03 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2013-03-28
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-03-27
03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-03-27
03 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document. I have one small
observation that those with more clue than I might …
[Ballot comment]
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.
2013-03-27
03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-03-27
03 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-03-26
03 Ted Lemon
[Ballot discuss]
I'm concerned that this appears to be a URN, not just any old URI, and (I think!) we expect URNs to uniquely identify …
[Ballot discuss]
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?
2013-03-26
03 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-03-26
03 Sean Turner
[Ballot discuss]
There's this RADEXT draft:
http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
Don't these two drafts do some of the same things?  Is there some way one can leverage the …
[Ballot discuss]
There's this RADEXT draft:
http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
Don't these two drafts do some of the same things?  Is there some way one can leverage the other?
2013-03-26
03 Sean Turner [Ballot comment]
I support Stephen's discuss.
2013-03-26
03 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-03-25
03 Pete Resnick
[Ballot discuss]
Before I open the can of worms on the webfinger list, I'd like to understand the reasoning behind this being a URI. I've …
[Ballot discuss]
Before I open the can of worms on the webfinger list, I'd like to understand the reasoning behind this being a URI. I've sent this to not only the author, chairs, and IESG, but I've copied the URI Expert. As far as I can tell, this is *purely* identifying URI; there is no concept that it will ever be "resolved" in a meaningful way. Normally, when we create such an identifier scheme, it's because we need the semantics of a particular kind of identifier in a place in a protocol that would otherwise take a URI. But looking at the webfinger document, the only place that this kind of URI will go is in the "subject" field of the JRD, which webfinger is defining and therefore needn't take a URI, or in the resource attribute of the URL to retrieve the webfinger information, which also needn't be a URI. Is there an instance in which this account identifier is going to be used in a context that *would* require a URI? I just don't see the point in creating a URI scheme whose only semantics seem to be, "It's an account of some sort that is only interesting to the thing you will hand this identifier". Please explain why this is an appropriate use for a URI.
2013-03-25
03 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2013-03-25
03 Richard Barnes [Ballot discuss]
Support Stephen's DISCUSS on this.  There should be an algorithm for comparing "acct:" URIs.  Otherwise, this looks very good.
2013-03-25
03 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Discuss from Yes
2013-03-25
03 Richard Barnes
[Ballot comment]
The word "discussants" may not be familiar to some readers.  "Participants in the discussion" might be a little clearer.


"""
Protocols that make …
[Ballot comment]
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.
2013-03-25
03 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2013-03-25
03 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-03-25
03 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-03-23
03 Meral Shirazipour Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2013-03-22
03 Stephen Farrell
[Ballot discuss]

I'll clear this when you tell me any one of the
reasonable answers:-) How do you compare acct URIs? Are the
host and …
[Ballot discuss]

I'll clear this when you tell me any one of the
reasonable answers:-) How do you compare acct URIs? Are the
host and userpart parts case sensitive? What about
punycode? Is fred@example.com the same as
%72red@example.com or %46red@example.com? Who defines
that? I think maybe you need to do it here but if not
then I think you need to say who does it where.
2013-03-22
03 Stephen Farrell
[Ballot comment]


- abstract: when we say "user" are we restricting that to
humans or can this be used for e.g. application servers
or hosts …
[Ballot comment]


- abstract: when we say "user" are we restricting that to
humans or can this be used for e.g. application servers
or hosts or other things?

- I was strongly reminded of kerberos principal names
here, but they don't get a mention. Ought they?

- Ought this document be held in the queue until
webfinger is done, just in case the example at the end of
section 3 (the "GET") turns out to need changing? (CHECK
WF isn't a normative ref)

- Does that abnf mean that %00@example.com is a valid
acct URI? Hmmm... do you want that? I think you really
ought add a security consideration that such URIs are
liable to cause s/w problems, e.g. the usual comparison
flaws in access control and possibly NULL end-of-string
errors.

- just checking: it is ok to allow spaces in acct URI
userparts, right? Would it be worth saying that and that
e.g. higher layer protocols will need to % encode those
to %20?
2013-03-22
03 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-03-21
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-03-21
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-03-14
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-03-11
03 Barry Leiba State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-03-11
03 Barry Leiba Ballot has been issued
2013-03-11
03 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2013-03-11
03 Barry Leiba Created "Approve" ballot
2013-03-11
03 Barry Leiba Placed on agenda for telechat - 2013-03-28
2013-03-08
03 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2013-03-06
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-02-28
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Charlie Kaufman.
2013-02-25
03 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-acct-uri-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-acct-uri-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have a comment about the IANA Action requested in this document.

This document requests adding a single URI scheme to the URI scheme registry located at:

http://www.iana.org/assignments/uri-schemes.html

The URI schemes to be added is:

acct

Currently the URI scheme registry is maintained through expert review as defined in RFC 5226.

NOTE: We will initiate a request and send this to the designated expert
for review.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-02-21
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-02-21
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-02-21
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2013-02-21
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2013-02-21
03 Cindy Morgan
Alternate Document Writeup

1. Summary

Draft name: "The 'acct' URI Scheme" draft-ietf-appsawg-acct-uri-03

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director …
Alternate Document Writeup

1. Summary

Draft name: "The 'acct' URI Scheme" draft-ietf-appsawg-acct-uri-03

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director


Draft Abstract:
"This document defines the 'acct' URI scheme as a way to
identify a user's account at a service provider, irrespective of the
particular
protocols that can be used to interact with the account."


This draft defines a new URI scheme that generically identifies
a user's account at a service provider without specifying a particular
protocol
to use when interacting with the account.
The need for this kind of URI has been identified during the
discussion related to the design of the WebFinger protocol;
however WebFinger is just one possible use for it, even if the
only one identified at the moment. account.


2. Review and Consensus

The ACCT URI has been discussed extensively within the APPSAwg
during the last year, it become a wg item in August 2012
and it has received very little/minor changes in the subsequent
updates.

The wg has not faced any significant point of difficulty or
controversial.

Before starting the APPSAwg last call, the draft has also been
sent to the uri-review@ietf.org list (on January 11th, 2013) for the
standard two-week review.
No one sent any comments there.

Moreover the APPSAwg has just raised a couple of editorial
issues that have been addressed in the current version of the draft.
Several open source WebFinger implementations already support it.


3. Intellectual Property

The author has confirmed conformance with BCPs 78 and 79.

4. Other Points

There is no new IANA registry created by this document.
2013-02-21
03 Cindy Morgan Note added 'Salvatore Loreto (salvatore.loreto@ericsson.com) is the document shepherd.'
2013-02-20
03 Amy Vezza IANA Review state changed to IANA Review Needed
2013-02-20
03 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The 'acct' URI Scheme) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The 'acct' URI Scheme) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'The 'acct' URI Scheme'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the 'acct' URI scheme as a way to identify a
  user's account at a service provider, irrespective of the particular
  protocols that can be used to interact with the account.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-02-20
03 Amy Vezza State changed to In Last Call from Last Call Requested
2013-02-20
03 Barry Leiba Last call was requested
2013-02-20
03 Barry Leiba Last call announcement was generated
2013-02-20
03 Barry Leiba Ballot approval text was generated
2013-02-20
03 Barry Leiba State changed to Last Call Requested from AD Evaluation
2013-02-20
03 Barry Leiba State changed to AD Evaluation from Publication Requested
2013-02-20
03 Barry Leiba Ballot writeup was changed
2013-02-20
03 Barry Leiba Changed protocol writeup
2013-02-20
03 Barry Leiba Ballot writeup was generated
2013-02-20
03 Barry Leiba Find the shepherd writeup here:
https://datatracker.ietf.org/wg/appsawg/management/shepherds/draft-ietf-appsawg-acct-uri/writeup/
2013-02-20
03 Barry Leiba Changed protocol writeup
2013-02-20
03 Barry Leiba Intended Status changed to Proposed Standard
2013-02-20
03 Barry Leiba IESG process started in state Publication Requested
2013-02-20
03 (System) Earlier history may be found in the Comment Log for draft-saintandre-acct-uri
2013-02-20
03 Salvatore Loreto IETF state changed to Submitted to IESG for Publication from WG Document
2013-02-18
03 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-03.txt
2012-12-03
02 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-02.txt
2012-10-18
01 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-01.txt
2012-08-15
00 Murray Kucherawy Changed shepherd to Salvatore Loreto
2012-08-14
00 Peter Saint-Andre New version available: draft-ietf-appsawg-acct-uri-00.txt