Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt

From: "Markus Lanthaler" <[email-masked]>
Date: Mon, 1 Jul 2013 19:19:43 +0200

I'm wondering whether it would make sense to add a feature allowing
associate a date to an account. This would address problems arising from
account recycling (think Yahoo). Maybe something like

   acct:[email-masked]?date=20130701

I think at the very least this should be covered in the security
considerations.

--
Markus Lanthaler
@markuslanthaler

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Monday, June 17, 2013 10:58 PM
> To: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-
> 05.txt
> 
> Based on IESG feedback, added a paragraph about putting a user@host
> address into the localpart of an 'acct' URI (percent-encoding the
> at-sign when doing so).
> 
> On 6/17/13 2:53 PM, [email-masked] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the Applications Area Working Group
> Working Group of the IETF.
> >
> > 	Title           : The 'acct' URI Scheme
> > 	Author(s)       : Peter Saint-Andre
> > 	Filename        : draft-ietf-appsawg-acct-uri-05.txt
> > 	Pages           : 9
> > 	Date            : 2013-06-17
> >
> > Abstract:
> >    This document defines the 'acct' Uniform Resource Identifier (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 IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-05
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-05
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > apps-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> 
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Jul 2013 12:02:11 -0600

> I think at the very least this should be covered in the security

IMHO we're beyond the point of adding new features to the 'acct' URI
scheme (it has completed Working Group Last Call, IETF Last Call, and
IESG review -- currently I'm working to address one issue about i18n
that arose during IESG review, so that the document can be approved for
publication).

However, a date could be included in an API or protocol that enables
applications to use 'acct' URIs. Is there a reason why this would need
to be included in the URI itself?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Markus Lanthaler" <[email-masked]>
Date: Mon, 1 Jul 2013 20:13:25 +0200

> that arose during IESG review, so that the document can be approved for

Sorry for bringing it up so late in the process.

> to be included in the URI itself?

Sure.. but I think the date should actually be a (perhaps optional) part of
the identifier, i.e., the acct URI. That would also make it easier to
exchange it between various applications and protocols.

--
Markus Lanthaler
@markuslanthaler

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Jul 2013 13:10:15 -0600

> Sorry for bringing it up so late in the process.

No worries. It happens. :-)

> exchange it between various applications and protocols.

Are you arguing that it would be easier or *safer*?

Also, it seems that your argument would apply to URIs in general (e.g.,
HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to
have ways to deal with stale/old HTTP URIs and the like. Thus I wonder
what in your mind is special about 'acct' URIs in this respect.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: DataPacRat <[email-masked]>
Date: Mon, 1 Jul 2013 15:16:13 -0400

> what in your mind is special about 'acct' URIs in this respect.

As I'm discovering in a discussion over at vcarddav, particular
accounts seem to have a much higher turnover rate than references to
those accounts. As part of a "signed vCard" proposal I'm making, an
extension to the format will allow date parameters to be added to any
field containing personal information, to cover just such an occasion.
(They can be applied to other fields, too, such as gender, should they
change over time.)

Coming in so late myself, I'm not sure whether this method should be
applied to the acct: URI; but since I'm using similar reasoning in my
own project, it seemed worth mentioning.

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 1 Jul 2013 21:34:33 -0400

Markus,

> exchange it between various applications and protocols.

Wherever the acct URI is used, I would assume a human initially provided the
URI (directly or indirectly via a simple "user@domain" entry).  How would
the human user know any date associated with an account?

I think recycling account identifiers is a "bad thing".  Set aside the acct
URI scheme itself for a minute.  Just imagine some prospective employer
performing a search one day for some Yahoo! user ID and discovering all
kinds of nasty things posted on the web several years ago by the previous
owner of that account.  The new owner might lose an opportunity for
employment.

Having a date as a part of any user identifier might help, but it is a
little difficult for the average person to use.  Could you imagine if all
account IDs looked like [email-masked]?  Not terribly
friendly.  We might as well just assign serial numbers to all accounts and
call it a day.

Paul

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 2 Jul 2013 10:31:10 +0200

On Monday, July 01, 2013 9:10 PM, Peter Saint-Andre wrote:
> >> applications to use 'acct' URIs. Is there a reason why this would
> >> need to be included in the URI itself?
> >
> > Sure.. but I think the date should actually be a (perhaps optional) part
> > of the identifier, i.e., the acct URI. That would also make it easier to

Well, both I think. It would make it simpler to exchange such information in
an interoperable manner and the resulting systems would be safer.

> HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to

That's true and AFAIK there have been efforts to do such things there as
well. Now of course we can't change HTTP URIs but since acct is just about
to be established we still have a chance to "fix" it there.

> what in your mind is special about 'acct' URIs in this respect.

It is specifically designed to denote a user account on some system.
Consequently it is highly security sensitive. We've seen the problem with
recycled email accounts that have been used for user identification. Again,
email is really old and we can't change it anymore. We have, however, still
the chance to improve the situation for acct and I think it would be
worthwhile to do so.

--
Markus Lanthaler
@markuslanthaler

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 2 Jul 2013 11:01:21 +0200

> the human user know any date associated with an account?

I'm not so sure about that, but in any case, why not simply use the current
date when the user enters the acct URI? That way the system would know once
for all that the user meant the account that was valid at that point in
time.

> owner of that account.  The new owner might lose an opportunity for

True, but if a date would have been used there as well it would be possible
to distinguish the two accounts.

> account IDs looked like [email-masked]?

What about [email-masked]?date=20130701

Is that still too difficult? The date wouldn't have to be necessary though.
A user can simply type in [email-masked] and the system adds the
current date automatically.

--
Markus Lanthaler
@markuslanthaler

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 2 Jul 2013 12:29:10 -0400

Markus,

> for all that the user meant the account that was valid at that point in

If you want the end user to enter the current date, there is no need: the
system could provide that.  However, end users are not usually performing an
account verification.  They're querying for information or sending an email
or something. 

> current date automatically.

You want to change the format of the email URI, too?

Paul

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Jul 2013 13:46:19 -0400

> account verification.  They're querying for information or sending an email

I've been reading this with interest, because I think there's an
interesting use case here.  But...

Yes, the idea is interesting, being able to say, "When I say
acct:[email-masked], I'm talking about the entity who had that
account back in 2007.  If the one who has it now is the same entity,
great.  If not, tell me, and don't do anything else."  It strikes me,
though, that that's a function of the protocol you're giving the URI
to, not one of the URI itself.  As Paul points out, taking this to the
mailto: URI (which would be very useful indeed, to be able to say, "If
this isn't the same user as the one from 2007, don't deliver my email
message!") would mean that something would have to understand what to
do with "mailto:[email-masked]?date=20070410".  At the moment, at
least, nothing does, and there's certainly no way in SMTP to convey
that.

A smart email client might be taught to turn that into
"acct:[email-masked]?date=20070410" and send off a webfinger (or
web-foot, or whatever) query, and then only do the message submission
if it got the go-ahead from that.  But in that case, the date-related
query belongs as part of the web-foot protocol, not as part of the
URI.

If you just want to use the URI as a convenient place to store the
validity date, I don't buy that.

Barry

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 2 Jul 2013 20:34:52 +0200

On Tuesday, July 02, 2013 7:46 PM, Barry Leiba wrote:
> to, not one of the URI itself.

I think that's really the main question: what does the acct URI identify? In
my opinion it identifies a user (account). There may be different users that
use the same "userpart" over time but that doesn't mean they are the same
users.

> As Paul points out, taking this to the

Of course you can work around such limitations by making the protocols
smarter but as history has shown, this is rarely done and leads (at least
sometimes) to massive problems.

Why do you think it belongs in the protocol?

> validity date, I don't buy that.

No, I think it goes a bit beyond that.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 2 Jul 2013 15:00:53 -0400

Barry,
 
> query belongs as part of the web-foot protocol, not as part of the

That kind of data element could be returned via WebFinger as a "property".  For example:

  "properties" :
  {
    "http://packetizer.com/ns/name" : "Paul E. Jones",
    "http://packetizer.com/ns/name#zh-CN" : "保罗‧琼斯"
    "http://packetizer.com/ns/activated" : "2000-02-17T03:00:00Z"
  }

It would be a matter of defining the property identifier (which is a URI) and the format of the date/time string.
 
> validity date, I don't buy that.

I don't either.  Humans have to enter these identifiers.  Dates in an identifier just make it more difficult for the human user.

Paul

---

From: Bob Wyman <[email-masked]>
Date: Tue, 2 Jul 2013 16:21:08 -0400

>    acct:[email-masked]?date=20130701
It seems to me that if one wanted to use dates as part of identifiers, you
would probably want to learn from tag URI's as defined in RFC
4151<http://www.ietf.org/rfc/rfc4151.txt>.
Tag URI's handle the problem of creating identifiers that are unique across
time -- which appears to be the use-case you're looking to address.

Thus, rather than the syntax you suggested, you'd be using something like
this: (i.e. use a comma, not a question-mark.)

acct:[email-masked],2001-09-15

The relevant ABNF bits from RFC4151 are:

> taggingEntity = authorityName "," date
> authorityName = DNSname / emailAddress
> date = year ["-" month ["-" day]]

...

---

From: DataPacRat <[email-masked]>
Date: Tue, 2 Jul 2013 17:11:21 -0400

> would probably want to learn from tag URI's as defined in RFC 4151. Tag
> URI's handle the problem of creating identifiers that are unique across time
> -- which appears to be the use-case you're looking to address.
>

While being inspired by tag:, you needn't feel limited by its
particular syntax. The date field on tag doesn't allow any more
precision than midnight on a particular day; and it only allows for
indicating particular moments rather than periods of time. It should
be simple enough to draw on ISO 8601's full range of time-indicators,
to allow (while not requiring) the indication of any particular second
(eg, 2001-09-15T12:34:56Z), or a period of time (eg, 2001-01-01/P1Y to
indicate the entirety of that year).

Thank you for your time,

---

From: Bob Wyman <[email-masked]>
Date: Tue, 2 Jul 2013 17:45:29 -0400

On Tue, Jul 2, 2013 at 5:11 PM, DataPacRat <[email-masked]> wrote:

> indicating particular moments rather than periods of time.

I think we'll find that support for "periods of time" is really not
necessary for reasonable use-cases. What the date does in this context is
allow you to say: "I am referring to the account that was named '
[email-masked]' during 2001-09-15." That should result in a single account
being identified (if we assume that account names aren't reused more than
once a day...)
If ranges were supported, someone might construct something that said: "I
am referring to any of the accounts that were identified as [email-masked]'
between 2001-01-01 and 2013-0101." Depending on how often account names
were reused, that could refer to a large number of accounts (i.e. >1).

It is tempting, whenever dates are discussed, to want to support the full
set of ISO specified date goodies, however, I really don't think it makes
sense in this context. Do we want to encourage acct names to be reused more
than once a day? Do we want to figure out how to address returning multiple
results in protocols that use acct? (What would WebFinger do if it needed
to return multiple results?)

People will typically have an identifier that was discovered by them on
some date in the past. Using something like WebFinger, what they will be
interested in asking is: "How do I contact the person or entity who used
the account "[email-masked]" on July 2, 2013?" I assume that it would be
possible for a WebFinger user or acct: processor to respond with some data
pointing to a current email address, etc. for the user or even some
indication that they are no longer living...

> It should

---

From: Graham Klyne <[email-masked]>
Date: Tue, 02 Jul 2013 18:12:57 +0100

There's also Larry Masinter's old proposal for dated URIs: 
http://tools.ietf.org/id/draft-masinter-dated-uri-08.html (now expired).

#g
--

---

From: Larry Masinter <[email-masked]>
Date: Wed, 17 Jul 2013 11:04:43 -0700

I'd like to finally move duri / tdb to RFC.  I think the last imponderable
question was whether it should be "Informational" or "Experimental".
And I'd need an AD sponsor.

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Graham Klyne
> Sent: Tuesday, July 02, 2013 10:13 AM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jul 2013 11:31:38 -0700

> And I'd need an AD sponsor.
...or adoption by a WG, if there's one that could take it within charter,
and has enough participant support to put the work into it.

Ahem.

-MSK