|From||“Conor P. Cahill” <firstname.lastname@example.org>|
|Date||Fri, 24 Oct 2003 07:43:54 -0400|
Stuart Jensen wrote on 10/23/2003, 7:00 PM:
From what I understand, the following is true:The format of the ResourceID is specific to the implementation of the service.
There is also an encrypted form used when the ResourceID is to be provided to third parties (e.g. a WSC)
The web service “registers” ServiceTypes and ResourceIDs with the Discovery Service.
A “client” will never have to create a ResourceID, it gets them from the Discovery Service. (as per the Discovery spec)
1) Does the Personal Profile Service have to register a unique ResourceID for every user record in its database? What if there are 500M users?
First off, there are circumstances where the ResourceID may be set to “implied”: When a service provider only allows one service instantiation of that type of service for a principal (e.g. the profile service provider only allows you to have one profile) and the service requires a security token on each message which identifies the principal whose profile is being accessed.
That said, there is still some form of registration required to notify the discovery service that this provider provides a profile service for the user. This can take place via a discover service registration or via some other, out-of-band mechanism in place within the COT. For example, an IdP may automatically establish an empty profile account on it’s backend systems when a new user registers and the association may be done out of band. Another example could be that an IdP assignes it’s own resource identifier for the service, creating a “virtual” profile account. the first time that the profile service sees a new resource Identifier, the profile creates a new account on-the-fly.
Note that the big issue with 500M users isn’t the ResourceID. It is the registration of the profile service provider on behalf of the user. But that too, can be handled through the same out-of-band operations described above in the case of large groups of users.
My personal $.02: I expect that most IdPs will provide a profile service as part of their “identity” package and that the association will be out-of-band, rather than an in-band registration allowed in the specifications. I see the in-band registration coming into play much more so with future services rather than the basic profile. Of course, that’s just my opinion and I’m sure there will be very reasonable cases that are quite different than that.
In the Personal Profile service, it appears that a “record” is a given user’s personal profile. When a <query> is made to the personal profile service, the only way the service will know which user record to access is by using the ResourceID.
Either the ResourceID, or it could be implied by the security token in the header. For example if I go to a web site, say puppies.com and use ID-FF to authenticate. When puppies.com accesses my profile using a security token generated off of the SSO environment, the profile service will be able to see that it is I who is sitting in front of Puppies.com and that I am the one who’s profile is being accessed. In such a case, the ResourceID can be set to “…-implied”.
2) Given an SP that wants to access the Personal Profile Service, that SP makes a discovery lookup call to a Discovery Service. In that lookup XML there is a ResourceID element. This SP probably only has a username or pseudonym for the current user. How does the SP tell the Discovery Service which user it wants to locate the Personal Profile service for? There must be some mapping from username/pseudonym to ResourceID? The specs claim that a client will never have to create a ResourceID, so the ResourceID sent in the Discovery Service lookup must be different from the ResourceID returned in the ResourceOffering…. right?
During ID-FF (with the 1.2 specifications), a discovery service resource offering can be included on the response, so the SP would use this resource offering to access the discovery service.
However, I would still say that you are correct in that there is, in the case that a user may only have one service instantiation — which isn’t always the case — a way to go from a name Identifier to the specific resource being accessed.
Note that the SP would not know this resource ID in such a case. Only the service provider (in this specific case the discovery service) would be able to go from a name identifier in a security token to a resource (not sure they need to actually generate a resource ID, just that they need to identify the local “account” being accessed).
———————————– If you would like to unsubscribe from this list, please click on the URL below: https://www.projectliberty.org/member/unsubscribe/ The Liberty Alliance liberty-dev mail list archive can be viewed at the following URL: https://www.projectliberty.org/devforum/maillist/liberty-dev/maillist.html
Partial thread listing:
|Re: [liberty-dev] ResourceID Question, (continued)|
|Conor P. Cahill (10/24/2003)|
|Jonathan Sergent (10/24/2003)|
|Jonathan Sergent (10/24/2003)|
|John Kemp (10/24/2003)|
|Re: [[liberty-dev] Liberty Alliance Question], (IGOR IVANOV)|