W3C home > Mailing lists > Public > public-xg-webid@w3.org > September 2011

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

From: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
Date: Fri, 30 Sep 2011 11:46:40 +0200 (CEST)
To: WebID XG <public-xg-webid@w3.org>
Message-ID: <62f8459a-2b07-43d9-94fe-42f5e82eea70@zcs>

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.

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

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"/>

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

| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

| http://www.semantic-web.at/

| web   : http://www.turnguard.com
| foaf  : http://www.turnguard.com/turnguard
| skype : jakobitsch-punkt
Received on Friday, 30 September 2011 09:47:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:46 UTC