W3C home > Mailing lists > Public > public-webid@w3.org > August 2012

RE: Integration of webid by SAAS providers

From: Emmanuel Dreux <edreux@cloudiway.com>
Date: Wed, 15 Aug 2012 11:57:02 +0000
To: Henry Story <henry.story@bblfish.net>
CC: Melvin Carvalho <melvincarvalho@gmail.com>, "public-webid@w3.org" <public-webid@w3.org>
Message-ID: <DF63ACC82673DB40A7AAC08FFA71DFBD27418A14@AMXPRD0610MB353.eurprd06.prod.outlook.com>
Hi Henry,

Thanks for these informations.
Our webid profile server is intended to companies who want to host it on premise (ie in DMZ), have the hand on it to automatically provision it (we are adding a provisioning layer to the profile portal, and integrating pki infrastructures of customers, + other functionalities like possibility to re download the certificate etc...).

When dozen of companies will own such profile servers, there will always be one who will want to migrate their infra to a new server, new url, etc...)
I like the approach of "The one that is most likely to work is to use URLs for identifying things, and then to use owl:sameAs relations between the two, with perhaps a deprecated tag on the old URLs".

But this means that every server side implementation of webid will have to know how to deal with it, probably requiring to be mandatory in every implementation?

Emmanuel Dreux
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

De : Henry Story [mailto:henry.story@bblfish.net]
Envoyé : lundi 13 août 2012 10:25
À : Emmanuel Dreux
Cc : Melvin Carvalho; public-webid@w3.org
Objet : Re: Integration of webid by SAAS providers

Thanks for the questions. We should add a wiki page for WebID migration and
dealing with multiple ones.

On 12 Aug 2012, at 23:27, Emmanuel Dreux <edreux@cloudiway.com<mailto:edreux@cloudiway.com>> wrote:

In our implementation, we can't rely on the URI of the location of the user profile:

You mean: can't eternally rely on the URI of the location of the user profile.
That is ok. The longer URIs last the better. :-)

=>  if the webid profile service is migrated to a different url, the link between the userID and webid  stored by the SAAS provider gets broken (ex if company A acquires company B that provides webid profile service).

Luckily companies don't get taken over every day :-)
One simple solution is to have the old profiles redirect to the new ones. Then slowly as certificates expire to re-issue certs with the new WebID. This is what Oracle did when it took over Sun. All blogs.sun.com<http://blogs.sun.com> URLs got redirected to oracle.sun.com<http://oracle.sun.com> ones.

=>  Therefore, the "link" between the userID of the SAAS provider and the webid profile must be independent of the profile's webserver infrastructure (independent of DNS name of the profile server).

The link where? On the web, in the SAAS database, elsewhere...?

=>  It cannot be either the public key.  In large companies who have PKI infrastructures, dozen of certificate revocation happen everyday (smartcard or laptops lost for example). This would introduce too much administration to have to manually "relink" accounts.

yes, the public key is not a good one, especially as users can have many of those.

There are many ways to work with migration of ids. The one that is most likely to work is to use URLs for identifying things, and then to use owl:sameAs relations between the two, with perhaps a deprecated tag on the old URLs. That is the least likely to present name clash problems. But even then when considered over time...

Therefore, we need an implementation where the userID of the SAAS provider would be stored in the webID profile (or for security reasons, a key that would not expose publically the userID name). The Webid stack integrated by the SAAS provider application would lookup this information in the profile to get his internal userID name.

Henry gave me an example showing that the specs are ready to accept such behavior. Ex:
<http://bblfish.net/#hjs> owl:sameAs <http://people.oracle.com/bblfish#hjs>;
  foaf:account[ a foaf:OnlineAccount;  foaf:accountName "bblfish"; foaf:accountServiceHomePage <http://facebook.com/> ]

yes, you could have some internal account name that ties the user to a local name.

We will need an implementation that works this way as well as a delegation server that will return this information too.
We are software editors working with several SAAS partners and we're ready to push webid to these partners.
For that, 1 point is mandatory: having a non intrusive webid integration:
-          Webid Authentication must be delegated to another instance/server to not impact the current infrastructure.
-          SQL or LDAP schema of the account database must not have to be modified in order to allow the webid integration. (eventually we can create a separate table shipped with the stack that would be a "mapping" table.

How the local mechanics works for your mapping the user id to the WebID is not important for WebID usage. Imagine that the WebID consumer gets all information only through Linked Data in RDF forms. It is important that such a consumer - who is constantly moving between contexts, from one company to another to a government agency, to a school, to a dentist, ... - be able to proceed only by consuming linked data. In your local tools, you can have the mappings be explicit, or implicit, written in code, pushed to an LDAP database, placed as patterns in configuration files, etc... That is non public information that the LinkedData consumer won't know about.

Is it a direction that some of you are taking, Is there already such implementation in PHP opensource that we can reuse or extend if it does not fit 100% our needs?

My guess is that many people use such mapping from SQL to RDF. There is a w3c working group on that. There are tools to make SQL to ldap mappings easier - D2RQ in the java world - and there is even a w3C working group for this.  But given how simple what you are trying to do is, I would just read the data where you have to and then produce the object model and the html/rdf serialistions you need by hand.

In functional programming you'd do a few mappings from one data model to the other.

I can't really speak about how php does things there.

At Sun Microsystems we once did a mapping from LDAP to RDF like that. It took less than a day.
Really there are too many tools I think that could be used to do this. The best is to do hack it once
and then again, and then you'll see what if there are abstractions you need.


Emmanuel Dreux
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

De : Melvin Carvalho [mailto:melvincarvalho@gmail.com<http://gmail.com>]
Envoyé : dimanche 12 août 2012 22:13
À : Emmanuel Dreux
Cc : public-webid@w3.org<mailto:public-webid@w3.org>
Objet : Re: Integration of webid by SAAS providers

On 9 August 2012 10:42, Emmanuel Dreux <edreux@cloudiway.com<mailto:edreux@cloudiway.com>> wrote:

I'm new to this DL and very interested in this technology.
This is much more a question for Melvin, but I'm sharing it in this DL.

If a SAAS provider wants to integrate the php webid implementation (https://github.com/melvincarvalho/libAuthentication) on top of his existing solution, how will he link the webid profile to his existing userIDs (stored in an account database)?

I think there's a newer library based in this, in development called webid realm ... perhaps andrei has some more details ...

- Will he have to write integration code or does this lib already implement code that lookups an account table to find the account matching the webid profile?

This library will allow you to login with a universal identity, ie URI.

- Will he have to extend his SQL or LDAP schema to store/link to webid profile?

If you have a URI in your table, simply compare, if not, the simplest way I think is to add a column to map the local ID to a universal one.

- What will be the "webid key" that links his internal userID to the webID profile?

In webid land it currently maps to an RSA key with an exponent and modulus.  The majority of users have one key, but many keys are possible.

The public key is stored both in the certificate and also in the public profile.  It is normally these two that are compared, unless you employ some kind of caching.  This means that your backend system need not store these fields.

--> Public key is subject to change if a cert is revoked / renewed
--> profile URI is subject to change if the providing service is migrated to a new URL

WebID keys tend not to change very often.

Traditionally you check this on each login, but if caching is employed you need to think about how long you want to store things.

An analogy might be with SSH which stores the public key on the initial login and also when the fingerprint changes.

Hope that helps!

Emmanuel Dreux
Tel: +33 4 26 78 17 58<tel:%2B33%204%2026%2078%2017%2058>
Mobile: +33 6 47 81 26 70<tel:%2B33%206%2047%2081%2026%2070>
skype: Emmanuel.Dreux

Social Web Architect
Received on Wednesday, 15 August 2012 11:58:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:34 UTC