W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: publickey link relation for WebFinger?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 16 Dec 2011 16:20:00 -0500
Message-ID: <4EEBB600.7000304@openlinksw.com>
To: public-xg-webid@w3.org
On 12/16/11 3:33 PM, Peter Williams wrote:
> 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

Yes, it's always easier when the ontology and the world is defines is 
readable.
Others see:

1. 
http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23  
-- main Ontology
2. 
http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23Certificate 
-- Certificate definitions within Ontology .

Kingsley
>
> On Dec 16, 2011, at 11:00 AM, "Bob Wyman" <bob@wyman.us 
> <mailto:bob@wyman.us>> wrote:
>
>>
>> On Fri, Dec 16, 2011 at 1:20 PM, Henry Story <henry.story@bblfish.net 
>> <mailto: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 <mailto:acct%3Abob@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 <mailto: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/
>>
>>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






Received on Friday, 16 December 2011 21:21:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC