[messaging] Affirmations // User attribute packets and resource location format

[Vincent Breitmoser]

(This mail is a follow-up to its replied-to mail :)

As mentioned, a user attribute packet is certified the same way a user id
is. This means we get certification including a timestamp for free, so the only
actual content we need in the user attribute is *where* the resource is located,
and possibly parameters on *how* to access it.

An important aspect here is that a client will in most cases require specialized
support for a resource type, like parsing a tweet from twitter, a gist from
github, or reading a dns record. One way to refer to different resources would
be by introducing a type registry and have a parametrized packet structure for
each. This would be inflexible and difficult to standardize though, I think
having human readability for unsupported resource types will aid ease of
implementation, extensibility and lead to more transparent de facto standards.

The established way to refer to a resource on the web is a URI. A generic URI
will not do in this case though, because that does not include the required
semantic implication about specialized client support. A good example is the
direct uri to a tweet on twitter, where the user only has partial control since
replies are shown on the page as well - a generic "parse page and look if the
data I want is there" mechanism will not suffice. My proposal is a new URI
scheme which bears this exact semantic, and supports additional parameters:

pgpid = "pgpid" ":" [options] "@" <absolute-URI>
options = ( option / flag ) [";" options]
option = key "=" value
flag = key
key = *(ALPHA / DIGIT)
value = *(<unreserved> / <percent-encoded> / ",")

With <absolute-URI>, <unreserved> and <percent-encoded> as specified in rfc3986.
The options always depend on the scheme of the sub-uri, and may specify
additional constraints or notations on the identified resource. Those are meant
to be extensible, but if a client does not know the meaning of ANY flag or
option, it MUST NOT proceed with verification. Some simple example uris:

pgpid:@https://twitter.com/TwitterUser/tweetid
pgpid:@dns:domain.com?TYPE=TXT

Those are the URIs as usual, but as part of the pgpid: scheme which implies the
identified resource can NOT (necessarily) be fetched by the usual semantics of
the URI. For the case where a generic "download and look for proof" mechanism is
the intended behavior, a flag can be used. Other useful options might be a
pinned certificate, or a timestamp associated with the resource:

pgpid:generic at http://domain.com/pgpid.txt
pgpid:fp=2D0AFDAFA16F4B5C0A43F3CB1D4752F9535507C0 at https://domain.com/pgpid.txt
pgpid:timestamp=1420465388 at https://twitter.com/TwitterUser/tweetid

Some more thoughts: The idea of adding semantics to a sub-uri has been done
before with the feed: and view-source: uri schemes. I considered putting the
options in paranthesis as done by the paparazzi scheme:
pgpid:(generic)http://domain.com/pgpid.txt
This has the benefit of being elidable for empty option lists, but is also
slightly confusing since the uri may be considered independent of the pgpid:
scheme it's a part of. I'm not sure at this point which way I like better.

I am also not a 100% on the scheme name "pgpid", but couldn't think of anything
better until now.

 - Vincent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150105/dfe63653/attachment.sig>