- From: Bob Wyman <bob@wyman.us>
- Date: Fri, 16 Dec 2011 13:59:47 -0500
- To: Henry Story <henry.story@bblfish.net>
- Cc: webfinger@googlegroups.com, Saint-Andre Peter <stpeter@stpeter.im>, Gonzalo Salgueiro <gsalguei@cisco.com>, Blaine Cook <romeda@gmail.com>, "Paul E. Jones" <paulej@packetizer.com>, Mark Nottingham <mnot@mnot.net>, public-xg-webid XG <public-xg-webid@w3.org>
- Message-ID: <CAA1s49WtrurQK1arsvWZjKNMnHc1uczRpTcyRHEmW5tN7RYfvQ@mail.gmail.com>
On Fri, Dec 16, 2011 at 1:20 PM, Henry Story <henry.story@bblfish.net>wrote: > > On 16 Dec 2011, at 19:03, Bob Wyman wrote: > > I'd really like to see a "publickey" link relation for WebFinger which > would point to one or more public keys that are associated with the acct:. > There doesn't seem to be anything like this in the existing registry. Does > anyone know if such a thing is defined anywhere else? If not, should I > create an Internet Draft to register publickey? Is there some reason that > we should *not* have a publickey link relation? > > > Well you can use WebID's cert:key relation to point multiple times to a > number of public keys. > There is an example in RDFa on http://webid.info/spec . (The spec has > just got a very large overhaul, so check it out again ) > As is clear from the name of the cert:key relation, it links to a certificate -- which is only one way to represent a key. Personally, I think this is the wrong way to do things. The link relation should indicate the semantic intent of the object which is linked to rather than its type, encoding, or whatever. Identification of media, encodings, etc. are, I believe, more appropriately handled via the "type" attribute. (Note: Salmon's Magic-Keys do not use certificates...) So, WebId's "cert"key" is close to what is needed, but not quite appropriate in that it lacks flexibility and imposes assumptions that aren't valid in all contexts. > > So I think Salmon being based on Atom does have space for you to put your > WebId in your atom. > Salmon Magic Signatures are not "based" on Atom and have no dependencies on Atom. Magic Sigs can be used with arbitrary payloads -- as long as that payload is base64url encoded in the Magic Signature. Both XML and JSON encodings are provided for the Magic Signature bits... > I think one could argue that the > atom:id field could play this role. > The atom:id field is defined clearly in the Atom Syntax specification and should not be used for anything other than its defined purpose. > I do that in my atom feed, which I am slowly reviving. > > http://bblfish.net/blog/blog.atom > > Then when you dereference the id you find in my atom you can get straight > to any number of my keys. > > > What I envision is something like the following: > > <Link rel="publickey" > type="http://salmon-protocol.org/ns/magic-key" > href="http://example.com/mymagic-keys.json"/> > > The idea is that, when using protocols like Salmon Magic Signatures<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>, > you would be able to say "This was signed with acct:bob@example.com's > key" and have people then use WebFinger to fetch the public key that should > be used to verify the signature. > > > I think if web finger were reliably to be able to point people to your > WebID then that would be a very good place to publish your public keys. > > > > (Yes, I am aware that Magic Signatures already defines a Property > serialization for magic-keys, however, I'd like to be able to link to the > keys as well as have a general mechanism, not specific to Magic Signatures, > for linking to keys that might be in other formats -- such as X.509 > certificates.) > > bob wyman > > > On Wed, Dec 14, 2011 at 2:17 PM, Peter Saint-Andre <stpeter@stpeter.im>wrote: > >> On 12/14/11 12:11 PM, Gonzalo Salgueiro wrote: >> > >> > On Dec 14, 2011, at 12:26 PM, Peter Saint-Andre wrote: >> > >> >> On 12/14/11 10:18 AM, Paul E. Jones wrote: >> >> <snip/> >> >> >>> My thinking for the link relations is that we ought to investigate >> >>> using the registry that was established by RFC 5988. So, rather than >> >>> have link relations sprinkled around the web, should we centralize >> >>> them at IANA? >> >> >> >> s/investigate using/use/ >> >> >> > I'm in full agreement here and immediately see the benefit of such >> > centralization. >> > >> > Peter - What is the best way to kick that off? I suppose a separate >> > draft/RFC would be required to establish an IANA registry for link >> > relations. If so, I can get started on making that happen. >> >> Mark Nottingham (cc'd) already did that work for you... :) >> >> http://tools.ietf.org/html/rfc5988 >> >> The registry is here: >> >> http://www.iana.org/assignments/link-relations/link-relations.xml >> >> Instructions for registering new relations are here: >> >> http://tools.ietf.org/html/rfc5988#section-6.2.1 >> >> However, Mark might be simplifying those procedures (in line with recent >> thinking about making it easier to interact with IANA). >> >> Some examples of forthcoming relation registrations can be found in >> three documents that I'm currently shepherding at the IETF: >> >> https://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/ >> >> >> https://datatracker.ietf.org/doc/draft-amundsen-item-and-collection-link-relations/ >> >> https://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/ >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> > > Social Web Architect > http://bblfish.net/ > >
Received on Friday, 16 December 2011 19:00:19 UTC