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

Cert refers not to certificate but the certificate type... In the ssl spec. Todate, there are 2 blobs/types: x509 and pgp (see gnu tls libraries for the pgp cipher suites)

If u look at my code, it distinguishes referencing the cert type from the x509 cert type specifically. Interpreting the context property as x509 required a specific cast (which would throw type checking errors if infact a pgp cert type was tied to the property).

Subtle. But it's the difference between code designed to type check as part of the assurance requirements and code that is a script parsing strings.

Sent from my iPhone

On Dec 16, 2011, at 11:00 AM, "Bob Wyman" <bob@wyman.us> 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. 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, 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/
> 
>