Re: Federated Authorization
On 25-Jan-07, at 1:36 PM, McGovern, James F ((HTSC, IT)) wrote: Modify your scenario as follows: - Tthe College of Physicians and Surgeons says she is a surgeon and is board certified for X number of procedures - A particular hospital says she is part of their team. Likewise, they also know that she plays different roles at other hospitals. Minimally we want to know when her admission priveleges expire - The university says she is part of their faculty and teachs in both the business school and engineering school. - the government says she is the business owner of her surgical practice and also serves in a board capacity on other boards Hopefully we can develop specifications which go deeper than just matching/correlation of identity and attribute. Hi James I don't follow your last comment. Would you elaborate? -- Dick___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Federated Authorization
Attempting to figure out to model deeper authorizations that aren't based solely on the identity and require additional information. In your first example, it didn't take into consideration what the individual can do, only that they had different identities which needed to be correlated. -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, January 25, 2007 4:43 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Federated Authorization On 25-Jan-07, at 1:36 PM, McGovern, James F ((HTSC, IT)) wrote: Modify your scenario as follows: - Tthe College of Physicians and Surgeons says she is a surgeon and is board certified for X number of procedures - A particular hospital says she is part of their team. Likewise, they also know that she plays different roles at other hospitals. Minimally we want to know when her admission priveleges expire - The university says she is part of their faculty and teachs in both the business school and engineering school. - the government says she is the business owner of her surgical practice and also serves in a board capacity on other boards Hopefully we can develop specifications which go deeper than just matching/correlation of identity and attribute. Hi James I don't follow your last comment. Would you elaborate? -- Dick * 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@openid.net http://openid.net/mailman/listinfo/specs
Federated Authorization
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@openid.net http://openid.net/mailman/listinfo/specs
Re: Federated Authorization
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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
