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: Sun, 12 Aug 2012 21:27:45 +0000
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: "public-webid@w3.org" <public-webid@w3.org>
Message-ID: <DF63ACC82673DB40A7AAC08FFA71DFBD274174C9@AMXPRD0610MB353.eurprd06.prod.outlook.com>
In our implementation, we can't rely on the URI of the location of the user profile:

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

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

  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.

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

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.

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?

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]
Envoy : dimanche 12 aot 2012 22:13
 : Emmanuel Dreux
Cc : 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
Received on Sunday, 12 August 2012 21:28:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:40 UTC