[OpenID] OpenID For Web Services

Pat Cappelaere pat at cappelaere.com
Wed Feb 28 21:21:09 UTC 2007

George, Paul, Nic and the rest of this Community,

Let me try again to avaid assumptions.

The intent here is a service oriented architecture based on REST services
within a trusted set of servers across several communities.

- Each server manages its own user set and respective web services.
- An individual web service will provide tailored response to a user that is
authenticated and authorized to access information based on a pre-agreed
upon permission set.  [So there is a need to do a profile exchange, make
sure that user has specific permission attribute.]

- Users should be able to present openid to main site and login once
(whatever that site is)
- User makes a query of sort (like I want thermal imagery for this area.
There is a major fire and we need to assess damage to send response crews).
- System tries to figure out what to do using discovery of what could be
available at that time (using catalog service for instance)
- System decides to access a site to task a NASA satellite or a local UAV
- System sends raw data to a university or JPL for processing
- System informs user that data is available.

Those SensorWeb Enabled data nodes might be transient and not known ahead of
time by the main site or system.
Those data nodes might need to get to specific user information from profile
(or at least know the permission set for that user).  Data nodes might have
to bill the customer for tendered services.

[This really is for emergency response and access to specific resources for
those dire cases where everyone might want to help.  In those rare
occasions, many communities may make their assets available to specific


> From: George Fletcher <gffletch at aol.com>
> Date: Wed, 28 Feb 2007 12:59:07 -0500
> To: Paul Madsen <paulmadsen at rogers.com>
> Cc: <general at openid.net>
> Subject: Re: [OpenID] OpenID For Web Services
> Paul Madsen wrote:
>> Hi George, how would the main site know for which remote sites it
>> required a cert/assertion?
> My assumption in the original use case, is that the "main site" is
> invoking a priori known remote sites.  The mash-up uses yahoo based
> services and hence wants to access flickr, mail and something else.
> I'm skipping the case where the "main site" needs to access a user's
> unique service (e.g. the user's picture service and that service could
> be one of n services [flickr, zooomr, picassawebalbums, etc] ).  This of
> course is the more interesting case but it requires the OP to be able to
> generate the appropriate cert/assertion for that service.  And more
> importantly, it requires the services to accept the OP generated
> cert/assertion.
>> Wouldn't the main site be more typically interested in obtaining a
>> token capturing the delegated rights for 'types' of remote service,
>> and not particular instances?
> Yes... I agree that the "main site" would want to get a token that it
> could use for "types" of services.  This should be doable with the right
> set of agreed upon conventions.  However, it sort of requires the
> identifier to be the same for all services.  I think there are dangers
> in that assumption.  To solve this, the OP would need to know the
> particular instance of the service being accessed by the main site so
> that it could generate a cert/assertion with the appropriate identifier
> for that site (e.g. my zoomr OpenID is different from my mail provider
> OpenID).
> Thanks,
> George
>> Paul
>> George Fletcher wrote:
>>> [Ok, if I've configured tbird correctly, this should come through to
>>> you and the general list as plain text.]
>>> If we go back to the original use case of a person accessing the
>>> "main site" and then the "main site" invoking remote web services on
>>> the user's behalf... it seems like this should still be doable with
>>> your certificates.
>>> 1. The user enters their OpenID URL at the "main site"
>>> 2. The "main site" determines the OP and re-directs requesting
>>> authentication and certificates for each of the remote sites it wants
>>> to invoke (specification of certificates could use the "Attribute
>>> Exchange" extension).
>>> 3. User authenticates to OP (prooveme.com) and grants consent for the
>>> requested certificates to be generated and returned to the "main
>>> site".  Note that this allows the certificates to be short-lived
>>> solving some of the certificate management issues.
>>> 4. The "main site" uses the certificates to access the desired remote
>>> sites
>>> It seems like this model would also work using SAML Assertions as
>>> well as certificates.  There might be a nice convergence path here.
>>> Thanks,
>>> George
>>> Nic James Ferrier wrote:
>>>> Hi George... I had to strip your HTML so I hope I got the gist of your
>>>> message. We don't all use HTML MUAs you know.
>>>> George Fletcher <gffletch at aol.com> writes:
>>>>> Very interesting. Are these long term certificates?
>>>> Could be. Again, that's up to the user. I'd suggest that if a user
>>>> wanted a long term relationship like:
>>>>   photo site -> blog
>>>> then they'd be granting that cert for a long time. They'll also be able
>>>> to turn the cert off at any time.
>>>>> Will prooveme.com manage the generation of new certificates and
>>>>> delivery to flickr when the old one is about to expire? or will that
>>>>> be the user's responsibility?
>>>> Yes.
>>>> I'd hope that if certificates take off in anyway we can come up with
>>>> more protocols, this time for distributing certificates automatically.
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

More information about the general mailing list