Re: publickey link relation for WebFinger?

On 12/16/11 10:13 PM, Peter Williams wrote:
>
>  how should I think?
>
> Is it possible for an ontology to "inherit" two ontologies?

Yes, there is an owl:import predicate for such relations.

>
> 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)/?

Yes, we do it all the time for much bigger endeavors e.g. DBpedia, 
Schema.org, FOAF, SIOC, Opengraph etc.. [1] .

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

Yes, you can do it by reading and coding, or letting the semantics do 
the reasoning thereby reducing the amount of logic processing in your code.

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

Yes, this is what you get from our services, should you opt to delegate 
certain aspects of the WebID protocol to them.

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

This could happen but, not at this stage. It would require granularity 
offered by reification semantics. Basically, making relations 
(statements) that describe relations (statements).

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

I believe that part is decipherable today if your profile is FOAF based. 
The description of services that ultimately unveil proxy endpoints is 
something that can also getting into your profile graph via SIOC (it was 
extended a while back to include service descriptions). Thus, your 
profile exposes a path to a service endpoint, and said endpoint could be 
a proxy service for WebID+OpenID, for instance.

Re. cut and paste approach, you can pepper your profile document with 
<link/> relations in <head/> or elsewhere (re. RDFa and Microdata) and 
still end up with a similar result i.e., work transparently with WebID 
or OpenID as has been demonstrated via openid4.me and our 
id.myopenlink.net/ods instance.

We are going to make another service that's decoupled from ODS so that 
its much easier to look at the end result in the same way you would 
openid4.me .

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

Yes!

Kingsley
>
>
> ------------------------------------------------------------------------
> Date: Fri, 16 Dec 2011 16:54:17 -0500
> From: kidehen@openlinksw.com
> To: henry.story@bblfish.net
> CC: public-xg-webid@w3.org
> 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 defined.
>
>
> 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:
>
>         1.
>         http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23
>         <http://uriburner.com/describe/?url=http://www.w3.org/ns/auth/cert#> 
>         -- main Ontology
>
>
>     I need to update the UML diagram there. It's out of date....
>     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 :-)
>
> Kingsley
>
>
>     Henry
>
>
>         2.
>         http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23Certificate
>         <http://uriburner.com/describe/?url=http://www.w3.org/ns/auth/cert#Certificate>
>         -- 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  <http://www.openlinksw.com/>
>         Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>         Twitter/Identi.ca handle: @kidehen
>         Google+ Profile:https://plus.google.com/112399767740508618350/about
>         LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>
>     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  <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>


-- 

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 Saturday, 17 December 2011 18:09:19 UTC