<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Federated Authorization</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2>The SAML specification is designed to target this precise
set of requirements, it has widespread support amongst vendors who support
enterprise class products.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2>If you want to have a third party accreditation of a
statement such as 'Dr Cripps is a licensed medical practitioner' it is going to
be exceptionally hard to persuade them to use any format other than either an
X.509v3 attribute assertion or a SAML assertion. From my point of view X.509v3
attribute assertions are not very interesting as they bind the statement to an
X.509v3 key certificate and thus a public key and not the entity that is
certified. This ties the whole system to X.509/PKIX as the authentication
infrastructure.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2>You can certainly use SAML in conjunction with an OpenID
authentication mechanism. As far as SAML is concerned all that it cares about is
that it has an identifier to bind to.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2>I don't think that the OpenID group wants to do the level
of architecture that would be required to address authorization either. To make
a statement of the type you suggest requires detailed consideration of the legal
and liability issues. SAML is designed to address these, that is why it has the
Audience constraint and is one motivation for the constraint
mechanism.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2>The pieces SAML lacks are standard mechanisms for discovery
and standard identifiers. These would not be at all hard to define.
Define the identifier to be a URI and instantiate an SRV based discovery
mechanism.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=484275816-18012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> specs-bounces@openid.net
[mailto:specs-bounces@openid.net] <B>On Behalf Of </B>McGovern, James F (HTSC,
IT)<BR><B>Sent:</B> Thursday, January 18, 2007 11:52 AM<BR><B>To:</B>
specs@openid.net<BR><B>Subject:</B> Federated
Authorization<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/rtf format -->
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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. </FONT></P><FONT
size=3><BR><BR>*************************************************************************<BR>This
communication, including attachments, is<BR>for the exclusive use of addressee
and may contain proprietary,<BR>confidential and/or privileged information. If
you are not the intended<BR>recipient, any use, copying, disclosure,
dissemination or distribution is<BR>strictly prohibited. If you are not the
intended recipient, please notify<BR>the sender immediately by return e-mail,
delete this communication and<BR>destroy all
copies.<BR>*************************************************************************<BR></BLOCKQUOTE></FONT></BODY></HTML>