<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Eve,<br>
<br>
Thanks for the explanation and peeling the onion.<br>
<br>
What you have stated is congruent with my desire to have the
business and policy aspects of the AS out of scope, reducing our
technical solution to being AS-agnostic. <br>
<br>
Within the context of the research use case I supplied, for example,
we can assume that the IRB would approve (at a policy level) the
business and technical actors for a research study. That would
imply that each AS has established appropriate trust relationships
with the ROs, RSs, and RqPs prior to issuing any authorizations.
This puts a nice bright line of business and technical preconditions
into the use case. While it might be administratively or
technically messy to add additional AS to the mix, as long as it
occurs out of scope for the use case, the technical solution is
agnostic.<br>
<br>
A similar AS-agnostic pattern would apply to the other use cases.<br>
<br>
I plan to do a next-level down rendering of the research use case,
showing the business and technical preconditions plus the inner
protocol flow. I'll let the group know when it's ready for review.<br>
<br>
Glen <br>
<div class="moz-signature">
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: (610) 644-2452<br>
Mobile: (610) 613-3084<br>
<a class="moz-txt-link-abbreviated" href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a></p>
</div>
<div class="moz-cite-prefix">On 12/15/15 12:37, Eve Maler wrote:<br>
</div>
<blockquote
cite="mid:CAMPbGmgNjF2z3RKxQ3vU5d2HjTpWkeRN6GduFLUkUPTei5TLWg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">Eliding old text below to make the thread
shorter...
<div><br>
</div>
<div>Here's my reading. The phrase is a term of art originally
crafted by Adrian. It's a bit analogous to business/IT
decisions about "build, buy, or outsource", only applied to
individuals' ability to be autonomous and have sovereignty
over their own lives (decisional autonomy, a key component of
privacy writ large) and data (a key component of data
privacy).</div>
<div><br>
</div>
<div><b>build:</b> Alice could literally write the AS code
herself and stand up her own service, say, under her deck at
home on her own hardware, or on a "blade server" at her ISP.</div>
<div><b>buy:</b> Alice could personally invest the time to
investigate and contract with a software solution supplier and
stand up her own service, again on one of the above hardware
choices.</div>
<div><b>outsource:</b> Alice could survey the available AS SaaS
services on the market and choose one.</div>
<div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Adrian's HIE of One open-source
project makes some of the above scenarios possible.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">You can imagine the layers of "terms
of service" or "EULA" or whatever that would/could apply at
each level of the hardware/software/trust relationship
stack, and we wouldn't want to stick our noses into 99% of
it except where the services and apps and operators first
have to "meet" at a technical level. The UMA WG, in fact, is
only sticking its nose into the UMA-specific part of it,
plus some exemplar agreements to give a flavor of what's
possible in those larger terms of service, EULAs, consent
receipts, etc. (The consent receipts might have a larger
proportion of UMA-specific content in them than the others!)</div>
<div class="gmail_extra">
<div>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP Innovation
& Emerging Technology<br>
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl<br>
Join our <a moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org OpenUMA</a>
community!</p>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Tue, Dec 15, 2015 at 9:25 AM,
Aaron Seib <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org"
target="_blank">aaron.seib@nate-trust.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Okay
– so what is the answer? I am assuming that the
first case that argued that the topic of number
and ownership of AS should be out of scope is
off but the language in the charter isn’t clear
to me yet… </span></p>
<span class="">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b>Support independent
authorization services and identity providers,
to be chosen by people who may build, run, or
outsource these services.</b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</span>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Support
is clear to me – it implies that it should allow
for so the first word I am good with.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What
is meant by an <b>independent</b> authorization
service? Specifically what are we saying?
Independent as in not ran by the government
(Private) or independent as in not ran by either
the Resource Owner or the person that the data
is about (the consumer who is the subject of the
PHI)?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What
is meant by “To be chosen by people”? We got
all kinds of people. The guy who runs the
lottery machine down the street is a people. At
least his mom thinks so. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Was
it meant to say that a consumer has a right to
choose the AS and IdP that they want used? That
would be clearer if it said it that way. The
last eight words seem to be tacked onto the end
‘who may build, run or outsource these
services’.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
am assuming it was intended to mean that “The
consumer should be supported in choosing a
standards based authorization service (and\or
identity provider) that is independently
operated by the consumer themselves or by
someone that they have selected. The
independently operated service may be operated
publically or privately and the consumer may
elect to leverage one operated by the Resource
owner.”</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
presume this is something that is doable,
right? The Resource Owner doesn’t incur any
additional burdens by selecting the independent
AS preferred by the consumer do they? If they
do we are going to have to figure out how to
limit that liability or they will never do it,
right?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
think the perception of a privacy risk is most
prevalent when the resource owner is also the
operator of the authorization server selected by
the consumer. The consumer should be familiar
with those risk before making that choice and
this should not be referred to as an independent
AS, right? </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
notion of which Independent AS’ are trustworthy
(and if a Resource Owner operated AS could be
trusted) is out of scope but I don’t think that
implies that their existence doesn’t have to be
acknowledged to get where we are going. Right?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Eve Maler [mailto:<a moz-do-not-send="true"
href="mailto:eve.maler@forgerock.com"
target="_blank">eve.maler@forgerock.com</a>] <br>
<b>Sent:</b> Tuesday, December 15, 2015 11:24 AM<br>
<b>To:</b> Aaron Seib<br>
<b>Cc:</b> Adrian Gropper; Crandall, Glen; <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a></a></span></p>
<div>
<div class="h5"><br>
<b>Subject:</b> Re: [Openid-specs-heart] The
Number and Ownership of Authorization Servers.</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Actually, what's in our
charter related to number/ownership/trust
around (UMA) authorization servers would
probably be <a moz-do-not-send="true"
href="http://openid.net/wg/heart/charter/"
target="_blank">these passages</a>:</p>
<div>
<ul type="disc">
<li class="MsoNormal">"The following
efforts are out of scope: ...
Development of related <b>trust
frameworks</b>."</li>
<li class="MsoNormal">(non-normative
background info:) "PoF’s primary focus
is on privacy and security protocols
that could demonstrate
machine-executable representation of
patient authorization and consent. At
the center of the effort is the notion
that both implicit and explicit
authorizations are necessary for the
exchange. The authorization could be
managed through a recognized/<b>trusted</b>
Patient Authorization Service that the
patient to could use mediate the
exchange of their own personal health
from a number of patient portals that
they may have access to."</li>
<li class="MsoNormal">"The specifications
must meet the following basic
requirements, in addition to specific
use cases and requirements later
identified by this Working Group: ... <b>Support
independent authorization services and
identity providers, to be chosen by
people who may build, run, or
outsource these services.</b>"</li>
</ul>
<div>
<p class="MsoNormal">What are the
technical requirements for profiling the
specs to support an AS that serves a
single RO (as in Adrian's vision), vs.
the business and legal requirements for
supporting an AS that serves a single
RO? If we identify those, then we'll be
within the reasonable limits of our
charter. I don't think there are many,
if any.</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Regarding what an
individual would prefer in their
lives, I'm guessing they would prefer
a single AS, all other things being
equal. But all other things aren't
equal... They might also prefer a
single login account in their lives --
but lots of people, faced with
"social" federated login at yet
another website/web app, still choose
to create yet another local login
instead because logging in with
Facebook gives them a creepy feeling.
Many of us at this table have worked
hard to make a new reality possible,
so that people could have the choice
of logging in with a "trusted
credential" of a certain type that
wouldn't feel creepy but natural
instead. And some of us are working on
an even bolder vision, the choice of
substituting a "third-party"
outsourced service with a 100% trusted
built/run one.<br clear="all">
</p>
<div>
<div>
<div>
<div>
<div>
<p><b>Eve Maler<br>
</b>ForgeRock Office of the
CTO | VP Innovation &
Emerging Technology<br>
Cell <a
moz-do-not-send="true"
href="tel:%2B1%20425.345.6756"
value="+14253456756"
target="_blank">+1
425.345.6756</a> | Skype:
xmlgrrl | Twitter: @xmlgrrl<br>
Join our <a
moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org
OpenUMA</a> community!</p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</body>
</html>