- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 26 Jan 2012 14:58:46 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid@w3.org
On 26 January 2012 14:55, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 1/26/12 7:17 AM, Henry Story wrote: >> >> On 26 Jan 2012, at 12:59, Kingsley Idehen wrote: >> >>> On 1/26/12 2:33 AM, Joe Presbrey wrote: >>>> >>>> The notion of self-signed WebID certificates (securely) expiring is >>>> invalid and quite easily misunderstood. There are no assurances for >>>> start/end dates (or any other properties, eg. WebID URI!) within the >>>> certificate itself. >>>> >>>> This is precisely why we resolve the WebID URI: to check if the claims >>>> in the certificate are true. We could also check the URI/LD to see if dates >>>> match, but we don't currently have schema for that, and why bother? >>>> >>>> Remove the "expired" certificate's public key from your FOAF/LinkedData >>>> if you want to deactivate it. Otherwise, >>>> >>>> re-self-sign: >>>> https://gist.github.com/1653329 >>>> >>>> You won't need to update your FOAF/LD as your Public Key will not >>>> change. >>>> >>>> >>>> On Wed, 25 Jan 2012, Mischa Tuffield wrote: >>>>> >>>>> Mischa *needs to generate a new cert I guess $todoList++. >>>> >>>> >>>> >>> +1 >>> >>> I've been mauling over this a bit and I don't think it really fits into >>> the Authentication realm. This is an Authorization realm matter. Basically, >>> one should be able to construct a resource access policy (via ACL) that >>> determines how certificate expiration is to be handled. >> >> ACL, stands for Access Control Lists, that is a document, such as the one >> developed by the Web Access Control ontology [1], which specifies which >> agents can have access to which resources. If you don't know what agent you >> have on the other end, you can't determine what rule to apply. So before >> applying ACLs we need to authenticate. > > > I understand that, and my position remains. Please don't assume that one > ontology defines the realm of ACLs, please don't go down that path. > > When I say ACL I absolutely do not mean the Access Control Ontology. > > I mean, anyone is in a position to construct a resource access policy based > on the credentials presented at resource access time. Thus, if I choose, I > can decide to not accept identity associated with an expired certificate. This is a great point there's 3 concepts I like to split out authn authz discovery They are like lego blocks that fit together to build a system > > >> If the server receives a certificate that is expired then you are now >> ignoring the first information that is reaching your server: > > > No I am not. The certificate is just carrying a set of claims. I decide what > to do with those claims. > > >> the one in the certificate. As such you are ignoring what the signer of >> the certificate released, and one would think that given that the person is >> using that Issuer, even if you don't know who that is, that should have a >> little weight in the process. Essentially the issuer would be saying: after >> that date don't count on me to vouch for this certificate - i.e.: it could >> have fallen into the wrong hands. So at the minimum you should be aware of >> that as a warning signal. But of course nobody has to listen to warning >> signals. One can override them. But not even noticing that these are warning >> signals would show someone to be an incompetent guard. >> >> Henry >> >> [1] http://www.w3.org/wiki/WebAccessControl > > > I've done policy based data access for 20+ years. Its how I built my > company. The rules for policy based access must be left to the publisher of > a given resource. The x.509 certificate is just a bunch of claims, and > that's basically it. What WebID does is introduce loose coupling and machine > accessible and comprehensible semantics. This provides a very rich substrate > for fine-grained access control policies. > > Again, ACL != a single ACL ontology (which defines a specific world view). > It is much more than that. > > >> >>> -- >>> >>> 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 >>> >>> >>> >>> >>> >>> >> 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 Thursday, 26 January 2012 13:59:23 UTC