<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I don't think the typical patient knows or cares about the AS, nor
be technically knowledgeable enough to express access authorization
rules.<br>
<br>
In the research use case, the business and technical preconditions
that I am thinking of are:<br>
<ul>
<li>The IRB has approved the research</li>
<li>The research project administration has acquired computing
resources (CDRNs) and security services (identification,
authentication, authorization, audit, administrative UI, etc.).</li>
<li>Prospective research subjects review the purpose the research
and consent to it via a wet signature on a form.</li>
<li>The research subject's consent implicitly authorizes clinical
data collection, and that data is registered in the research
projects authorization server. In this case, and only for the
research, the AS operates on behalf of all research subjects.
It is independent of any other AS in the ecosystem.</li>
</ul>
A specific instance that I have in mind was a research study that my
wife participated in last September. She enrolled as a research
subject for post-operative pain relief for a total shoulder
arthroplasty with biceps tenodesis, comparing intra-operative
injections of a pain-relief drug versus spinal nerve-blocks. She
signed the research consent form. The clinical data associated with
her operation and post-operative experience then became available to
the researchers. At no point was she involved in the technology
that supports it, but I'm sure that the operative report and nursing
charts were provided to the researchers. (I'm happy to report that
pain relief was sufficient for her to spend only one night in the
hospital.)<br>
<br>
I suspect that other research studies follow a similar pattern, with
patients only signing a consent that then enables the research
treatment and data-collection processes.<br>
<br>
Glen <br>
<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 13:45, Debbie Bucci wrote:<br>
</div>
<blockquote
cite="mid:CAG6zQ1Y0ymyX7CFOEC8OLLqtKCA-ETLs9fEx0Mh+ZGFSO2PGGw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>Would a typical consumer really know or care that they have
an Authorization server? Isn't it more likely a service will
have an AZ at its core but the service would have to offer
something more? Perhaps that service will be widely used
enough that an enterprise or corporate entity would respect -
perhaps replicate authorizations permissions - but I
personally think its unrealistic to believe there will only be
just one. Alice may not even know it.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 15, 2015 at 1:25 PM, 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 vlink="purple" link="blue" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">“The
consumer should be supported in choosing a standards
based authorization service (and\or identity
provider) that is independently operated by the
consumer themselves (build or buy) or by someone
that they have selected (outsourced where the
consumer pays a third party to do this on their
behalf or allows another to sponsor its operation on
their behalf). The independently operated service
may be operated publically (the state of Deleware
may make one available to all Delewarians) or
privately (the third party that gets paid by the
consumer or the sponsor of the consumer) <s>and</s>
or the consumer <b>may</b> elect to leverage one
operated by the Resource owner.”</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">I
think that answers the question of ownership.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">Now
–I don’t think there is an answer to the number of
AS’ a person may have. Clearer we all start with
having 0. Some people may work their way up to
having one or more. I gather that some consumers
will want more than one but I don’t think I
internalized the why but I may not have to know the
why. If I understand correctly the RO can only ever
rely on one on a transaction basis. The rule could
be to always use the latest one I pointed you to. </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">In
a practical sense each RS may have to have on set up
for those consumers that haven’t got one otherwise.
So maybe that is the default behavior? A RO should
disclose nothing until the consumer has indicated
which AS to use and then only use the latest one
that they pointed you to.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">I
don’t think we can get any more granular then that
right? You might have 3 AS that you have configured
and you gave the enterprise that owns the RS where
your mental health data one the URL for your AS<sub>1</sub>,
the enterprise that has your physical therapy
records the URL for AS<sub>2</sub> and the PCP you
have seen since you lived at home with your mom is
still using AS<sub>3</sub>.</span><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"></span></p>
<span>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">Aaron
Seib, CEO</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">@CaptBlueButton
</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> (o)
<a moz-do-not-send="true" href="tel:301-540-2311"
target="_blank" value="+13015402311">301-540-2311</a></span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">(m)
<a moz-do-not-send="true" href="tel:301-326-6843"
target="_blank" value="+13013266843">301-326-6843</a></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="http://nate-trust.org" target="_blank"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt;text-decoration:none"><img
src="cid:part4.02040906.06060908@securityrs.com" border="0" height="48"
width="205"></span></a><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"></span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
</span>
<p class="MsoNormal"><b><span
style="font-family:"Tahoma","sans-serif";font-size:10pt">From:</span></b><span
style="font-family:"Tahoma","sans-serif";font-size:10pt">
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 12:38 PM<br>
<b>To:</b> Aaron Seib<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</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">Eliding old text below to
make the thread shorter...</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><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.</p>
</div>
<div>
<p class="MsoNormal"><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.</p>
</div>
<div>
<p class="MsoNormal"><b>outsource:</b> Alice
could survey the available AS SaaS services on
the market and choose one.</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Adrian's HIE of One
open-source project makes some of the above
scenarios possible.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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!)</p>
</div>
<div>
<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"
target="_blank"
value="+14253456756">+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"> </p>
<div>
<p class="MsoNormal">On Tue, Dec 15, 2015 at
9:25 AM, Aaron Seib <<a
moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a></a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </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></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">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="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span></p>
<p class="MsoNormal"><b><span
style="font-family:"Tahoma","sans-serif";font-size:10pt">From:</span></b><span
style="font-family:"Tahoma","sans-serif";font-size:10pt">
Eve Maler [mailto:<a
moz-do-not-send="true"
href="mailto:eve.maler@forgerock.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a></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">openid-specs-heart@lists.openid.net</a></span></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re:
[Openid-specs-heart] The Number
and Ownership of Authorization
Servers.</p>
</div>
</div>
<div>
<div>
<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" 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"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr style="color:rgb(160,160,160)" align="center"
noshade="noshade" size="1" width="100%"></div>
<span>
<p class="MsoNormal">No virus found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com" target="_blank">www.avg.com</a><br>
Version: 2016.0.7294 / Virus Database: 4483/11177 -
Release Date: 12/14/15</p>
</span></div>
</div>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-heart"
target="_blank" rel="noreferrer">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
</blockquote>
</div>
<br>
</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>