Federated Authorization

[Dick Hardt]

Hi James

As Phillip states, SAML can be used to represent the assertion.

Interesting that you mention a Doctor example. A use case that we are  
working on uses a Surgeon (Sally) who needs to prove:

- Tthe College of Physicians and Surgeons says she is a surgeon
- A particular hospital says she is part of their team
- The university says she is part of their faculty
- the government says she is the business owner of her surgical practice

With OpenID, each of these authorities could make a claim about  
Sally's OpenID. This could be expressed as a SAML assertion.

When accessing a resource that requires one of Sally's verified  
attributes, Sally (using her OP) proves she is a specific OpenID  
Idenitifier and also provides the SAML assertion(s) that prove that  
identifier has been verified to belong to a surgeon, team member,  
faculty member, business owner.

We have created an example for something anyone on the net can have  
verified, their email address. I'll post separately about that.

-- Dick

On 18-Jan-07, at 8:51 AM, McGovern, James F ((HTSC, IT)) wrote:

> I would love to see folks hear that also blog not only continue to  
> discuss federated identity but also consider of the course of  
> several additional postings also talk about the need for federated  
> authorization. Consider an example where a Doctor in a hospital is  
> having an electronic interaction with a healthcare insurance  
> provider. The hospital should be the identity provider while the  
> entity that licensed the Doctor for given sets of practices should  
> be responsible for certain forms of authorization.
>
> If we only talk about identity without authorization, the  
> conversation will result in lots of great software where folks who  
> create them won't make any money since consumer-centric  
> interactions have volume without corresponding revenue.
>
>
>
> ********************************************************************** 
> ***
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information. If you are not the  
> intended
> recipient, any use, copying, disclosure, dissemination or  
> distribution is
> strictly prohibited. If you are not the intended recipient, please  
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ********************************************************************** 
> ***
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070118/11bd4ac2/attachment-0002.htm>