<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Trying to re-awaken this thread... To summarize (hoping others will correct me as necessary), Bob P. was positing that part of the policy requirement governing access might be around the assurance level of a requesting party's identity. &nbsp;If we can make some (big-leap) assumptions that assurance levels are well enough standardized on a global level and that UMA-protected claims (Domenico's trust model) can deliver up identity claims that accurately carry a level of assurance, we may be able to allow Alice to set authorization policies like this: "<a href="mailto:Bob@gmail.com">Bob@gmail.com</a> can get access to this if I'm assured, to NIST:LOA2, that it's him". Domenico's proposal about the requesting party having to approve release in real time gives us a place for that party to *log in* and consent, which gives a place to capture a fresh authentication assertion.</div><div><br></div><div>Other thoughts?</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Eve</div><br><div><div>On 28 May 2010, at 12:31 PM, Eve Maler wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Bob and Jeff gave me the go-ahead to forward the thread below, so that others could benefit and participate...<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Bob Pinheiro &lt;<a href="mailto:kantara@bobpinheiro.com">kantara@bobpinheiro.com</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">28 May 2010 7:21:53 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">j stollman &lt;<a href="mailto:stollman.j@gmail.com">stollman.j@gmail.com</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Eve Maler &lt;<a href="mailto:eve@xmlgrrl.com">eve@xmlgrrl.com</a>&gt;, "Maler, Eve" &lt;<a href="mailto:Eve.Maler@paypal.com">Eve.Maler@paypal.com</a>&gt;, Iain Henderson &lt;<a href="mailto:iain.henderson@mydex.org">iain.henderson@mydex.org</a>&gt;, "<a href="mailto:mark@smartspecies.com">mark@smartspecies.com</a>" &lt;<a href="mailto:mark@smartspecies.com">mark@smartspecies.com</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: IIW Topic: UMA and the Law</b><br></span></div><br>
<div bgcolor="#ffffff" text="#000000">
Well, as I understand the UMA protocol, the requester *does* know where
to find the AM.&nbsp; According to the protocol, the steps are:<br>
<ol>
  <li>Requester attempts to access resource at host and is given AM's
requester_token_uri endpoint</li>
  <li>Requester visits this endpoint, providing its desired scope of
access</li>
  <li>AM either provides access token, rejects authorization, or asks
requester for claims</li>
  <li>Requester provides claims as requested, until access token
request either succeeds or fails definitively</li>
</ol>
Bob<br>
<br>
On 5/28/2010 7:10 AM, j stollman wrote:
<blockquote cite="mid:AANLkTinGOmlyJ9lgpu4FzSPheKnuEwXjBr9qFCVkKGJ1@mail.gmail.com" type="cite">Bob,<br>
  <br>
Consider the possibility that you might choose one AM to define
policies for multiple information stores on multiple hosts.&nbsp; Some of
these information stores may include highly sensitive information,
while others would contain information of low sensitivity.&nbsp; <br>
  <br>
Next consider that the requester interfaces with the user and the host
and need not know the identity of the AM.&nbsp; Because the requester does
not know the identity of the AM, it would be difficult for him to find
the AM, take advantage of its low requirements for authentication to
'break in", and change policy settings for information he is seeking
from a particular host(s) in order to gain access to information that
he would otherwise be denied.<br>
  <br>
Unless I am missing something in the UMA model, this would suggest
these two points would suggest that the authorization levels of host
and AM need not be the same.<br>
  <br>
Jeff<br>
  <br>
  <div class="gmail_quote">On Thu, May 27, 2010 at 5:50 PM, Bob
Pinheiro <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:kantara@bobpinheiro.com">kantara@bobpinheiro.com</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Eve,<br>
    <br>
I think I was trying to make the point that someone using a personal
information store to maintain and possibly distribute sensitive
personal information may want to protect access to that information
with something stronger than just a username and password. &nbsp;If that's
the case, and a user of a personal information store also uses an
authorization manager to allow requesters to have access to parts of
that information, then the level of assurance/authentication strength
needed to establish and modify those access policies should be the same
as that used for direct access to the information store. &nbsp;So rather
than the host demanding that a user authenticate to it with the same
strength that the user uses at the AM, maybe it should be the other way
around....the AM should require authentication to it with same strength
as is used at the host. &nbsp;I'm assuming that here that the user would
first setup the personal information store, then go to the AM to define
access policies. &nbsp;It doesn't seem to make sense that someone would go
to an AM first without there being some information store already there
for which access policies needed to be defined. &nbsp;So.....setup
information store first, including authentiction method, then go to AM
to define access policies, and AM checks to determine what
authentication strength is used at the information store.<br>
    <br>
Anyway, hope that makes sense.<br>
    <br>
Bob<br>
    <br>
On 5/25/2010 12:05 AM, Eve Maler wrote:<br>
    <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
Bob,<br>
      <br>
Thanks for the thoughtful message! &nbsp;A few thoughts back, below.<br>
      <br>
On 24 May 2010, at 10:25 AM, Bob Pinheiro wrote:<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
didn't attend IIW, but I did notice some online notes posted on this<br>
topic of UMA and the law. &nbsp;One point brought up in the notes is "What<br>
would incentive hosts to accept an authorization manager's policy<br>
decisions, and all the liability implications thereof?"<br>
        <br>
Although I haven't been following the UMA and Information Sharing work<br>
closely, I assume that the "host" is the place where the user's personal<br>
information store, or other protected resource, resides. &nbsp;Presumably<br>
&nbsp; &nbsp; <br>
      </blockquote>
Yep, that's correct.<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">also
the act of creating and managing a personal information store on<br>
some host is independent of any prior or future relationship the user<br>
may have with an authorization manager. &nbsp; So let's say the user creates<br>
a personal information store, and wants to protect access to it using<br>
some type of Assurance Level 3 credential. &nbsp;[Presumably the personal<br>
information store may contain sensitive or otherwise valuable<br>
information, and the user may want to protect access to it using<br>
something stronger than just a password]. &nbsp;Assume the user is able to<br>
use an OpenID backed by a browser certificate or OTP token, or perhaps a<br>
managed Information Card that provides level 3 assurance.<br>
&nbsp; &nbsp; <br>
      </blockquote>
The way UMA currently works, if the user wants to limit access to that
resource to particular identities with particular strengths of
assurance, the user would craft policies at the authorization manager
that say so. &nbsp;(This assumes the AM offers this kind of policy as part
of its service.) &nbsp;And any requester approaching the host to get access
would then have to satisfy the policies appropriately. &nbsp;So far, so
good...<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Since
the UMA protocol requires that the host get an access token from<br>
the authorization manager representing the user's consent to provide<br>
access to the user's information according to the policies set by the<br>
&nbsp; &nbsp; <br>
      </blockquote>
Despite claiming that you're not following closely, this is an
extremely nuanced observation. :-)<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
        <br>
user, it would seem that the level of assurance required for user<br>
authentication to the personal information store should be the same<br>
(AL-3) as that required for access to the authorization manager for<br>
purposes of setting or changing policy. &nbsp;A mismatch (such as AL-2 for<br>
authentication to the authorization manager, while the personal<br>
information store requires AL-3) would seem to increase the host's risk<br>
of providing unauthorized access by a requesting party, and hence its<br>
potential liability.<br>
&nbsp; &nbsp; <br>
      </blockquote>
So you're saying that the *host itself* might demand that the user
authenticate to it with the same strength that the user uses over at
the AM? &nbsp;Interesting. &nbsp;There are all kinds of practical problems here
having to do with comparing authentication strengths (if assurance
levels aren't used), and even if they are used, they're very likely not
the right tool for the job. &nbsp;See this blog post for thoughts on why
M04-04 isn't the right set of use cases to apply to non-gov work:<br>
      <br>
      <a moz-do-not-send="true" href="http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/" target="_blank">http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/</a><br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">However,
what's not clear is whether setting up (and subsequently<br>
accessing) a personal information store, or using the services of an<br>
authorization manager, should require that the user's true identity be<br>
known, as would be required when obtaining a level 3 credential. &nbsp;So for<br>
instance, couldn't I just create a personal information store<br>
anonymously, and use an authorization manager to manage access to that<br>
information, provided that the method of authentication to both ensures<br>
(with the same degree of confidence) that the authorized user who "owns"<br>
the personal information store is the same one who is managing access to<br>
it via the authorization manager?<br>
&nbsp; &nbsp; <br>
      </blockquote>
Yes, I think so.<br>
      <br>
The purpose of UMA is to govern access by others (other people, other
services on their own behalf, or other services on the authorizing
user's own behalf) as delegated by the authorizing user. &nbsp;I think
you're talking about the last case of the three, and certainly -- as we
can see in OAuth today -- the user can be entirely pseudonymous at the
entire set of sites, and even use different pseudonyms at each. &nbsp;(The
requester access token functions as a very lightweight pairwise
host/requester pseudonym, along with representing the authorizing
user's grant of access. &nbsp;And of course the host access token gotten in
step 1 functions as an AM/host pseudonym.)<br>
      <br>
For example, in that third use case, Alice has a login at her AM, a
login at the host, and a login at the requester service.<br>
      <br>
(Keep in mind that the requester may have to supply "claims" that have
nothing to do with a unique identity. I suppose the host could object,
independently of Alice's policy wishes, if some claim supplied by the
requester service is at a lower "assurance" or quality than the means
Alice uses to log in at the host, but this hasn't come up to date.)<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Assuming
that true identities aren't necessarily required, this points<br>
to a gap in the current assurance level scheme described in OMB04-04.<br>
In other words, what's needed are strong authentication methods that are<br>
not necessarily tied to someone's actual identity. &nbsp;This would enable a<br>
self-issued Information Card (which currently would have to be<br>
considered at AL-1 since its identity claims are self-asserted) to be<br>
used as a high-assurance authentication credential for UMA and personal<br>
information stores, since it provides stronger cryptographic functions<br>
but without the identity proofing.<br>
&nbsp; &nbsp; <br>
      </blockquote>
We're definitely singing the same tune on this! &nbsp;My blog post linked
above tells the tale... &nbsp;And Paul Madsen followed up with this one:<br>
      <br>
      <a moz-do-not-send="true" href="http://connectid.blogspot.com/2010/01/taxonomy-of-federated-applications.html" target="_blank">http://connectid.blogspot.com/2010/01/taxonomy-of-federated-applications.html</a><br>
      <br>
BTW, UMA has a design principle (DP9) about protecting the privacy of
the authorizing user:<br>
      <br>
      <a moz-do-not-send="true" href="http://kantarainitiative.org/confluence/display/uma/UMA+Requirements" target="_blank">http://kantarainitiative.org/confluence/display/uma/UMA+Requirements</a><br>
      <br>
As may be necessary from time to time (actually, constantly :-) in most
access control systems, Alice may need to craft policies around access
that mention *specific* identities that are allowed to gain access,
which unmasks at least those identities, though they may themselves be
pseudonyms;"<a moz-do-not-send="true" href="mailto:bob@gmail.com" target="_blank">bob@gmail.com</a>" &nbsp;is a favorite example we use. &nbsp;We
have imagined scenarios for both self-asserted identities and
third-party-asserted ones, but not for any finer gradations. &nbsp;Our
claims system could *theoretically* handle any LOA requirements -- but
as I say, this is the first time it's come up. &nbsp;Interesting indeed!<br>
      <br>
FWIW,<br>
      <br>
&nbsp; &nbsp; &nbsp; &nbsp;Eve<br>
      <br>
&nbsp; <br>
      <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bob<br></blockquote></blockquote></blockquote></div></blockquote><br></div>

</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; font-family: Courier; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><br class="Apple-interchange-newline">Eve Maler</div><div><a href="mailto:eve@xmlgrrl.com">eve@xmlgrrl.com</a></div><div><a href="http://www.xmlgrrl.com/blog">http://www.xmlgrrl.com/blog</a></div></span></span>
</div>
<br></div>_______________________________________________<br>WG-UMA mailing list<br><a href="mailto:WG-UMA@kantarainitiative.org">WG-UMA@kantarainitiative.org</a><br>http://kantarainitiative.org/mailman/listinfo/wg-uma<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Courier; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><br class="Apple-interchange-newline">Eve Maler</div><div><a href="mailto:eve@xmlgrrl.com">eve@xmlgrrl.com</a></div><div><a href="http://www.xmlgrrl.com/blog">http://www.xmlgrrl.com/blog</a></div></span></span>
</div>
<br></body></html>