RE: publickey link relation for WebFinger?

 how should I think? Is it possible for an ontology to "inherit" two ontologies? for example, could openlink define an ontology that is a merge of RDFS (maintained by teh foaf project) and webid (maintained by the webid IX)?  As it stands, Im going NOTHING with the webid spec except read it like any IETF spec. Im not consuming it, as a source of rules. Id love to be able to have my RDFS engine point to an openlink URI, and that not only powers the RDFS inferences but also "powers the webid engine". It might also define data URIs (that point to cert blobs). is there anyway to have the ASK query be described (in the webid spec) and for an engine to learn the latest query - much like my RDFS engine learns the latest inference rules (and the openid property/relation)? Id love to be able to say in my profile: look at the openid "extensions" of the webid spec, which teaches the app how to relate the webid URI, to my foaf:openid URI, to a data URI that points at the cert as a cert blob. At that point, I can imagine my foaf card acting as a "modern" certificate store (key ring in the webid spec world), that powers how an advanced browser locates the users private key - in order to engage in SSL client authn. It also powers the openid plugin in my browser (or the websocket application, in the HTML5 era).  Date: Fri, 16 Dec 2011 16:54:17 -0500
Subject: Re: publickey link relation for WebFinger?


    On 12/16/11 4:40 PM, Henry Story wrote:

        On 16 Dec 2011, at 22:20, Kingsley Idehen wrote:
           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).


        Currently we don't use the X509 and PGP classes in the
          WebID specification. They were in the ontology initially to
          help me think about how these pieces related to one another.
          So if you are using them I don't think it is something


    Remember, we extended the ontology in our own namespace. My response
    was more to do with reading the ontology and how it describes crytpo
    components. Ditto the separation of x.509 and PGP certs. 




                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: 


            -- main Ontology


        I need to update the UML diagram there. It's out of
        That's another reason to keep things simple btw. Just
          having something as simple as we have, is a lot of work to
          deal with!

    The more accessible and readable material is the easier it becomes
    to spot and fix issues :-)






            -- Certificate definitions within Ontology . 




                On Dec 16, 2011, at 11:00 AM, "Bob Wyman" <>




                  On Fri, Dec 16, 2011 at 1:20
                    PM, Henry Story <>


                            On 16 Dec 2011, at 19:03, Bob Wyman

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

                    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.


                          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



                              The idea is that, when using
                                protocols like Salmon Magic
                                  Signatures, you would be able to
                                say "This was signed with'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 <>

                                      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:




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


                                        > 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


                                      Mark Nottingham (cc'd) already did
                                      that work for you... :)




                                      The registry is here:




                                      Instructions for registering new
                                      relations are here:




                                      However, Mark might be simplifying
                                      those procedures (in line with

                                      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:











                                          Peter Saint-Andre






                                                   Social Web







Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:


                                  Social Web Architect






Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:


Received on Saturday, 17 December 2011 03:14:22 UTC