Re: publickey link relation for WebFinger? (was: Re: using HTTP 'From' request header)

On 16 Dec 2011, at 19:59, Bob Wyman wrote:

> 
> 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.

One should not judge a relation by its name (alone)! :-)

 cert:key relates to keys such as RSA or DSA keys directly as mathematical objects.
The details are at the namespace document 

   http://www.w3.org/ns/auth/cert#



> 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.

yep that's what we do. We just go for the mathematically defined keys.

> 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.

Nothing imposes no restrictions and is 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...

Ok. I heard of them being used a lot in atom.

>  
> 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.

oops sorry, I meant the atom:uri element.

 http://tools.ietf.org/html/rfc4287#section-3.2.2

That is pretty much close to the definition of WebID

   The "atom:uri" element's content conveys an IRI associated with the
   person.  Person constructs MAY contain an atom:uri element, but MUST
   NOT contain more than one.  The content of atom:uri in a Person
   construct MUST be an IRI reference

The only distinction is that WebID refers to a Person.


>  
>  I do that in my atom feed, which I am slowly reviving.
> 
>     http://bblfish.net/blog/blog.atom

No I have not added that yet. I'll do that when I get my whole site behind https.

> 
> 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, 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/
> 
> 

Social Web Architect
http://bblfish.net/