IdP ID for UserIDs in GlobalRegistry?

[sgoendoer]

There was a short discussion in Chatilion regading including additional information in the Global Registry. There wasn't a final decision on this, so I'd like to discuss this here as an open issue.

1.) Do we need / want to store a IdP ID (e.g. [email protected]) for a UserID?

2.) If there are multiple IdP IDs for a UserID, how should this be handled? Possible solution: Store a list of IdP IDs for each UserID. Restrict the user to one IdP ID per CSP/UserID.

3.) Do we need / want to store information about the type(s) of Hyperties "behind" a UserID in the DHT? Again: How is this handled if there are multiple types of Hyerties for a UserID?

[jmcrom]

IMNSHO The link UserID/IdP-ID has nothing to do in the Global Registry since it involves only domain-bound entities.

What could be more relevant would be the mapping GUID/IdP-ID (I remember making a brief comment on paperboard in Chatillon) sincd it would be a limited extendion of the current Global Registry encompassing IdP as another kind of domain-bound service just like CSP.

However, the original conception of mapping GUID to UserID was a way to solve the issue of Global Reachability. I am still not clear with the practical interest of this mapping: as I said in issue #11 it could be a usecase for Discovery service.

And BTW the multiple IDs existing throughout the services is somehow privacy-firendly...

[rebecca-copeland]

Hi WP4

Such mapping of GUID to a user-chosen IdP has the advantage of increasing usability - users can give their identifiers as [email protected].... far more friendly. Such an identifier can be linked to several services, not just reTHINK.
However,if the identifier [email protected] at the IdP has several associated service identifiers (including GUID / UserID), which service is invoked? -

• the same service as the caller's service? (this is reTHINK, and all other OTTs)
• the service that the user is currently logged onto?
• let the browser invoke a 'default' service that the receiving user has pre-configured?

Somehow this all feels familiar.

Rebecca

[rjflp]

It seams to me that different persons are talking about different things in this thread.

@sgoendoer The original purpose of the Global Registry is to provide a mapping:
GUID -> list of UserIDs ( user@service_provider )

As a SP can choose to use an external service provider, I believe that it has already been determined that a UserID can have one of two formats:

• user@SP (when the identity is local to the SP)
• user@IdP@SP (when the SP accepts to use an external IdP)

From the name of the SP, one must be able to derive the name of its message node and thus reach its Domain Registry.

What is being discussed in issue #11 is different: it is the use of an UserID ( i.e. user@SP or user@IdP@SP) to find the user's GUID and then all the services he uses.

@rebecca-copeland I would say that using the same service as the caller would be the priority. Otherwise, after contacting the SPs' Domain Registries, we learn about the available hyperties and what resources / data schemas they support / are currently logged on. This should be used to decide which hyperty to use. Should several hyperties be available that provide the same functionality, it would be up to the caller (application and then user)?

[fbeierle]

At yesterday's advisory board meeting, @sdruesedow and @pchainho showed a demo. As far as I understood, you had to enter a IdP-identifier and the URL of the Domain Registry.

Is the IdP-Identifier used as the username with the SP/Domain Registry? If so, what if I want to use different IdP-Identifiers or none at all?

[pchainho]

That should also be possible but I guess if I'm anonymous I won't be "discoverable"

[fbeierle]

My question is: How does it work so far in the demo? What identifiers are used?

[pchainho]

IDP Identifiers

[jmcrom]

I think this case is what @rjflp described as "user@IdP@SP" which makes perfectly sense IMHO in current Global Registry since it's a possible format of service UUID

[sbecot]

Yes, I was about to answer: the demo shows what happens if you already know the identifier of the person you want to join, after the use of the discovery and the global registry, that, with the GUID gives you access to this information: the domain and the identifier, but is not showable yet.

[fbeierle]

In the demo, IdP identifiers were used. In the specification of the Domain Registry, UserIDs are used to retrieve the running Hyperties for a user:
https://github.com/reTHINK-project/dev-registry-domain/blob/master/docs/DomainRegistryUserManual.md#get-hypertyuseruser_id

To me, it's still unclear, how exactly it is done in the demo.

Regarding the proposed scheme of "user@IdP@SP". Would this be an example?
user: [email protected]
IdP: google.com
SP: rethink.mysp.com

[ingofriese]

I think to use the IdP identifier is not consistent. It was a good work around to deal with the missing discovery (shame on us ;-) We have a first version

But if I want to be conected to Felix. I have or I discover his GUID. Resolving the GUID should finaly lead to endpoints. These endpoint should belong to Felix voice, video, chat or whatever hyperties.

Felix can use on his side whatever IdP he likes to authenticate >> see the IETF draft where we write about the independend IdPs <<

[jmcrom]

@ingofriese if you have a way to plug this search form onto the discovery service this would be just fine!

[ingofriese]

The discovery with search engine, maintaining profiles, addapting search policies etc. is ready so far. Now I'm about to connect with the Global/Domain Registry. And I think the problems coming with the details.
I think we should at least write down (one page/post or short text) how it works accross discovery/registry/start hyperty/ connect to a second hyperty.) Who has to provide which parameter over which interfaces.
I think we have all the pieces but still need work to plug everything together.

[sgoendoer]

@ingofriese, @fbeierle, and me had a discussion yesterday to clarify the interfaces between the Registries and the Discovery a bit more.

A question raised here was "Why does the IdP-Identifier even play a role in the process of establishing a connection at all?"

Lets use the following scenario:

User Alice has two different IdP-IDs: [email protected] and [email protected]. Her GUID is "GUID_A". When another user Bob wants to connect to her, he will get her GUID e.g. from the Discovery. Then, the Registries are used to discover the endpoints to connect to. Here, he does not care (or need to know) which IdP-ID Alice is using to run a certain Hyperty.

As far as I understood, IdP-IDs (with the need to explicitly specify the CSP's domain when establishing a connection) is a kind of workaround until the whole cascade of Registries requests are integrated and automated.

[rjflp]

@sgoendoer

A question raised here was "Why does the IdP-Identifier even play a role in the process of establishing a connection at all?"

There needs to be an identifier of the user with the SP. We can either use the IdP Id used to register with the service or we can have the user choose a new one. But in the latter, we have to worry about colisions, mapping from one to the other, etc. The former is just simpler.

@fbeierle

Regarding the proposed scheme of "user@IdP@SP". Would this be an example?
user: [email protected]
IdP: google.com
SP: rethink.mysp.com

I would say you have one @ too many. The user would be the one registered with IdP, so:
user: something
IdP: google.com
SP: rethink.mysp.com

[fbeierle]

But if "[email protected]" is my Google ID, Google won't be able to identify me only providing "something", right?

[ingofriese]

@rjflp you said : There needs to be an identifier of the user with the SP.
Why? if alice wants to call bob. Bob needs some account at his CSP right. But Alice?
As long as Alice has and endpoint URL where she can send a message to Bob she don't need an identifier of Bob. So if we have the end point then there is no need for an additional identifier.
Right?

[rjflp]

@fbeierle You are right. Then it's probably something like "user"@idp@sp and user can be "anything@anything".

@ingofriese When Alice wants to call Bob, the registries will only be used to locate Bob's endpoint, not Alice's. So, I think we are on the same page.

[pchainho]

We already have syntax defined a long time for these situations:

https://github.com/reTHINK-project/dev-service-framework/tree/develop/docs/datamodel/core/address#user-url-type

and

https://github.com/reTHINK-project/dev-service-framework/tree/develop/docs/datamodel/core/address#user-account-in-a-service-provider

@ingofriese @rjflp service providers accounts should not be mandatory, that's what we currently have today. Even if there is a service provider account, it could be identified with an IdP Identifier.

[ingofriese]

@pchainho .......yes I agree but also identifyer shouldn't be mandatory
two anonym endpoints (descibed by some arbitary urls) should be enough for a communication

[rjflp]

@ingofriese It should be possible. But what is the use case? When would you like to call someone without knowing whom you are calling? Some kind of http://chatroulette.com/ ?

Anyway, in this case, the Registries would not be used, so this is a moot point.

[ingofriese]

@rjflp I think there is are fundamental different understandings of IDs.
If I say to you for example ...if you want to make a Hotel Reservation call 0800 030123636...I give you an endpoint and no identifier. Because I don't now who has duty at the reception desk right now

This example transfered in a reTHINK world. I discover a Hotel profile and want to call it. I just get back a more or less anonym endpoint http://t-labscloud.instance12126436146.

another example:
If I discover you under your nickname profile "abc" I just click on your GUID and expect to get back an endpoint and a connection to that. Whether you are logged in as [email protected] or as [email protected] is not important. I write something to "abc" or "Interieur design company" etc.

This leads to my next question to you regarding the domain registry.
If I find e.g. you (your GUID) in the discovery (search engine) and the get from Global Registry
domain URL. What is next ? Can I contact the domain registry for more infromation? Do you have an IP-address, where you service is running. Can I contact it directly? Or is it just available via a hyperty?

[ingofriese]

In the IP world I get a IP address and send my package there regardless of the identity that owns that IP-address. Identity is handled on another layer.. Registries deliver more or less the current ip-addresses. (in reTHINK the endpoint-URLs) Registries are a kind of DNS.
And discovery is a kind of google.

[rjflp]

@ingofriese
A complete call would follow these steps (this is a simplification of the final parts):

1. Perform a search on the (a?) Discovery Service and obtain a GUID
2. Using that GUID, obtain the information about the SPs being used by that "person" (UserIds)
3. From the UserIds, derive the address of the Message Node for each SP, and contact the Domain Registry (via Message node) in order to find the suitable hyperties for the type of communication intended (video, audio, chat, etc)
4. Select the hyperty to use (automatically or with user intervention) and use the SP's Message Node to contact it, using the address learned from the Domain Registry queries in step 3.
5. Establish direct communication (P2P) with the hyperty or continue to comunicate using the Message Node

If you already have the GUID, you can start at step 2.
If you already have the UserId, you can start at step 3.
If you already have the hyperty id, and you know the SP, you can start at step 4

[ingofriese]

How does step 3) could exactly work. Is there an example domain URI running.
Can I start a Hyperty with SP and UserID as parameters in one call.
Or do I have to start a hyperty and type it manually?

[pchainho]

Currently, all our demos start from step3.

Pls have a look at our testbed:

https://hybroker.rethink.ptinovacao.pt/examples/

or even at TLabs testbed:

https://rethink.tlabscloud.com/examples/

I guess @sdruesedow can also explain better how TLabs own demo work

[sgoendoer]

@rjflp @pchainho @ingofriese
I totally agree with @ingofriese regarding #12 (comment)
In my understanding, users in reThink are identified by their GUID. So when users get in contact with each other, they "call" the other party's GUID. You call an GUID to reach one of the Hyperties running "behind" it. I don't see the need to specify which IdP-ID (on top of that) I want to get connected to - Alice shouldn't even bother about whether Bob uses Google or Facebook as his IdP.

Don't get me wrong. I don't see a problem with having an IdP-ID incorporated into the UserIDs. But calling/identifying a user using his IdP-ID/CSP-Domain somehow makes me question why we designed the GlobalRegistry with explicitly domain-agnostic identifiers in the first place.

If we identify users not (only) by their GUID, but also - or even more importantly - by their IdP-ID, we'll need to store the GUID and all known associated IdP-IDs for each contact in our address books as well. Because Alice would want to call "A Hyperty running for BobGUID with the IdP-ID [email protected]" instead of "A Hyperty running for BobGUID". So if we need to maintain a (local) list of used IdP-IDs (which we cannot simply get from some service like the GReg as they should somehow be verified - otherwise those would only be arbitrary strings). Then, we could just as well store the associated CSP with that. And then, we don't really need a GlobalRegistry anymore and we are back to walled gardens with the lock-in effects we wanted to get rid of.

For the one's who thought "TL;DR":

I oppose the idea of using the IdP-ID as a way for Alice to "identify" Bob, who she is calling. Alice should simply use the GUID to identify Bob.

[fbeierle]

Using IdP-identifiers in the UserIDs, we need (as far as I understand):

• username
• IdP domain
• SP domain
• messaging node URL
• domain registry URL

As far as I understand, both the messaging node URL and the domain registry URL can be derived from the SP domain.

I think, the User URL @pchainho linked in #12 (comment) (https://github.com/reTHINK-project/dev-service-framework/tree/develop/docs/datamodel/core/address#user-url-type) does not contain the SP domain and thus will not work as a UserID.

The User Account in a SP (https://github.com/reTHINK-project/dev-service-framework/tree/develop/docs/datamodel/core/address#user-account-in-a-service-provider) should work:

Using this example:
username: [email protected]
IdP: google.com
SP: rethink.mysp.com

The schema of "user@IdP@SP" would give:
[email protected]@[email protected]

The linked acct schema would give:
acct://rethink.mysp.com/user://google.com/[email protected]

Please someone correct or confirm!

[rjflp]

@sgoendoer A user can call another by specifying his GUID. The rest of it happens behind the scenes...

Following friday's WP4 conf call, I created this related issue reTHINK-project/dev-discovery#2

[pchainho]

@fbeierle Currently we need User URL and SP domain but the idea would be to only use User URL when using the Global Registry / Global Discovery.

I think, the User URL @pchainho linked in #12 (comment) (https://github.com/reTHINK-project/dev-service-framework/tree/develop/docs/datamodel/core/address#user-url-type) does not contain the SP domain and thus will not work as a UserID.

I don't know what you mean by UserID but the user URL was defined as a user identifier that is independent of the service provider to support user portability.

The linked acct schema would give:
acct://rethink.mysp.com/user://google.com/[email protected]

Please someone correct or confirm!

This seems correct but you can also use the GUID in the user account in case you don't want to be constrained by any IDP eg acct://rethink.mysp.com/user-guid://<guid>

[rjflp]

@pchainho

This seems correct but you can also use the GUID in the user account in case you don't want to be constrained by any IDP eg acct://rethink.mysp.com/user-guid://

What is the use case of this?
The goal of using the GUID is being independent from the SP, which will probably not be known.
Furthermore, would the SP know the user's GUID? Would it keep a mapping from GUID->User for its own users?