Re: WebID integration

> On 14 Oct 2015, at 04:17, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 10/13/2015 04:10 PM, henry.story@bblfish.net wrote:
>> WebID Integration ( http://webid.info/spec/ ) -----------------
> 
> Responding to the above in a separate thread...
> 
>> Verifying the public key is the first step. A public key can
>> actually be used as a global identifier. But Web Access Control using
>> just public keys would be quite cumbersome: - a user may have one
>> public key per device and even per application - public keys should
>> be changed if there is reason to believe the private key may have
>> been compromised, or if the hardware has been lost - filling ACL
>> files with public keys would render them quite heavy ( though here
>> clearly using a URL to refer to the key can solve this problem )
> 
> +1, agreed.
> 
>> Now it is also possible that a key be linked to one or more WebIDs 
>> (which logically would therefore refer to the same agent). These 
>> WebIDs could potentially be on different domains.
> 
> +1 to this as well, reasoning seems solid.
> 
>> * should the WebID be passed in the signature?
>> 
>> It may make more sense to have a WebID header, and for to be added
>> to the headers field in the headers attribute of the Signature
>> request.
> 
> This isn't necessary given the way the Credentials stuff works at
> present. Here's all that happens:
> 
> The provided keyId in the HTTP signed message is a URL, like so:
> 
> curl -sk https://dev.payswarm.com/i/manu/keys/4
> 
> which has data about the key that includes the owner, like so:
> 
>  "owner": "https://dev.payswarm.com/i/manu",
> 
> and dereferencing that URL like so:
> 
> curl -sk https://dev.payswarm.com/i/manu
> 
> gives you the bi-directional claim that the resource/WebID owns the key
> in question:
> 
> "publicKey": [
>    {
>      "type": "CryptographicKey",
>      "owner": "https://dev.payswarm.com/i/manu",
>      "label": "2012-09-27 Access Key",
>      "id": "https://dev.payswarm.com/i/manu/keys/4"
>    },

yes, we agree on the answer of having the key links to the profile,
and the profile to the key. This was the example I gave in n3

<android#key> cert:modulus "..."^^xsd:hexBinary;
       cert:exponent 65537;
       is cert:key of <profile#me> .

( "is cert:key of" is the inverse of cert:key is the equivalent of 
your "owner" )

I should not have phrased my problem here in terms of "making 
more sense". I would have no problem having as you my key link
back to my identity. But I wanted to have an answer to those who
don't want that.  The situation could develop as follows:

Someone starts with just a public key to authenticate to a web
site. The public key works as with FIDO as an indirect identifier
( via the inverse functional cert:key relation ) to identify the user,
who remains a blank node. Perhaps at some point the user decides he
is fine to use this key to authenticate to other sites too ( going 
beyond FIDO here ). These sites could if they talked to each other
and trusted each other work out that the same person with one public
key had been on their different web sites. But that is about all.
( Perhaps there are cases when this is actually useful ).

Now suppose further that the user wishes to identify to another web
site but now with an identity that ties into his social network, 
because he actually wants to converse with friends and family ( over
an encrypted channel over Tor perhaps, so that outsiders have no idea
who he is talking to ). Here he wishes to continue using the public
key he used previously but with the social identity. But perhaps he
does not wish to tie the key to the identity, so that he can continue
using it in other places too.

That was the use case I was considering.

One could answer that creating a new resource that links the key to
the user is a cheap operation. But I suppose public keys are things
that should be public, so the less information placed there the
better ( for some people ).

So I was just considering the option where that link is made in 
the header of a request, rather than being published in the key
resource. Does that use case make sense?


>> * How does the server hint that a WebID may be of interest to it?
>> The signatures spec seems to say that this can be done by passing
>> the field in the "headers" parameter of the WWW-Authenticate header.
>> 
>> "The server may optionally specify which HTTP headers it expects to 
>> be signed by specifying the `headers` parameter in the 
>> WWW-Authenticate header."
>> 
>> So this means I suppose that the server can add some headers such as 
>> User used by the SoLiD group. But then we still have the issue 
>> mentioned previously of what happens if the client sends more than 
>> one signature...
> 
> When/Why would a client send more than one signature? Is this a common
> use case?

I was thinking of a case where someone wanted to prove their age and
their sex, and the two credentials for this had been signed by two
different keys.

> 
>> * I suppose a future WG could have as one of its roles to merge the 
>> cert ontology that WebID uses with the one that digitalbazaar has 
>> been developing.
> 
> I think there are 3 ontologies that will need to be merged/play together
> nicely. JWK, WebID cert ontology, and the security ontology.

ah yes: 
- JWK  (JOSE) http://self-issued.info/docs/draft-ietf-jose-json-web-key.html
- WebID Cert: http://www.w3.org/ns/auth/cert
- Security ontology: https://w3id.org/security#

> Merging
> them isn't a difficult task, it's just time consuming and then the
> question arises about whether or not we want to have 3 different key
> formats. The more key formats, the more complex the libraries to
> implement the stuff we want to implement. I'm not making an argument for
> or against, just an observation.

Turning JOSE into an ontology may not be that much work, it may just require
creating a namespace and that could presumably be the w3c cert namespace, as the
two seem to be at the same level of detail: that is right at the core of 
cryptography. One would need both a good cryptographer and an ontologist to
do that, but also some type of industry support.  If possible with JSON-ld
magic it would be possible to crytsalise a JSON-LD document in such a way 
that it looked exactly as a JOSE document...

I think there will always be a need to keep links to the old binary encodings
around, but if one can get away from those, that would help clarity. The nice
thing about your signatures is that one can sign an rdf graph in a transparent
manner, and not have to produce a hex encoded blob. That makes it easy to 
see for example what is being made public when publishing a key. A pem encoded
certificate may contain all kinds of information that is only visible to those
with the right binary tools.

So the relation from the security ontology to a PEM makes sense as the easiest
way to cover the most, but at the same time it makes it pretty opaque to most
developers what is being published, and leaves us stuck with the binary formats.

At present I am more keen on developing applictions that give those who
use linked data a huge competitive advantages, because until that time 
one does not get the ears of the right people.

So the question is not I think should one get a full certificate ontology
( as compatible as possible to JOSE ) but when will it make sense to invest
the effort... That is why I have kept the cert ontology minimal and limited
to RSA keys for the moment. 

> 
>> On the whole the spec looks pretty good.
> 
> Glad to hear that, Henry, and thanks for taking the time to review it
> and put some serious thought into how it could be applied to your work.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
> 
>

Received on Wednesday, 14 October 2015 09:54:18 UTC