Re: design issue when dereferencing a foaf-profile with public key

On 9/30/11 5:46 AM, Jürgen Jakobitsch wrote:
> hi,
>
> thank you all for your input and pointers!
>
> i was originally asking this with respect to the question if it would be considered a good idea
> to separate the PublicKey from the webID-profile with the following scenario in mind.
>

It is a good idea.

> say i have my bank account and my cia-mysql-admin account protected by webID, go on holiday
> and want to be able to reach my home-pc for some reason, so it's online.
> while i'm sitting on the beach, somebody breaks into my house, launches firefox and simply
> uses my webID ("view certificates" and the page history should limit the number of webpages
> to try to log in to to a manageable degree).
>
> now, if i have my PublicKey in a separate place, i could put it into offline mode easily,
> even if i'm not a programmer who simply edits his webID-profile, but a normal user (otto normalverbraucher in german).

Your scenario needs a little fleshing out though. Remember, you have an 
x.509 cert generated at some point. This action always precedes the 
creation of a public key and WebID in a data space (wherever that might 
be).  Thus, you will need to invalidate the x.509 cert(s) on your home 
machine by deleting existing WebID-CertPublicKey relations (triples) 
from your profile space.

Based on the above, you could generate a new cert from you phone or 
table device on the beach; assuming that at generation time you're able 
to place a new values in X.509 SAN that points to a new or old data 
space into which you have new WebID-CertPublicKey relations (triples).
> when separating keys from profiles there could be a concierge-service, where you could log in
> using a standard login method (user-pass) and put your key into offline mode. this makes the key
> not-dereferenceable and nobody could login using the certs of a stolen computer.
>
> example :
>
> <foaf:Person rdf:about="http://www.someuri.org/card#me">
>   <!-- seeAlso, whatever -->
>   <foaf:hasPublicKey rdf:resource="http://concierge.org/public-keys/2342"/>
> </foaf:Person>
>

Delete the data space relations, as per comment above and all associated 
X.509 certs are rendered useless. SPARQL supports DELETE so that isn't a 
problem.

Kingsley
>
> wkr http://www.turnguard.com/turnguard
>


-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen