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 |