(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@http://domain.com/pgpid.txt pgpid:fp=2D0AFDAFA16F4B5C0A43F3CB1D4752F9535507C0@https://domain.com/pgpid.txt pgpid:timestamp=1420465388@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
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
