Re: WebID integration

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"
    },

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

> 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 03:18:10 UTC