[Openid-specs-heart] The Number and Ownership of Authorization Servers.
Glen Marshall [SRS]
gfm at securityrs.com
Tue Dec 15 19:19:22 UTC 2015
I don't think the typical patient knows or cares about the AS, nor be
technically knowledgeable enough to express access authorization rules.
In the research use case, the business and technical preconditions that
I am thinking of are:
* The IRB has approved the research
* The research project administration has acquired computing resources
(CDRNs) and security services (identification, authentication,
authorization, audit, administrative UI, etc.).
* Prospective research subjects review the purpose the research and
consent to it via a wet signature on a form.
* 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.
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.)
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.
Glen
*Glen F. Marshall*
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com
On 12/15/15 13:45, Debbie Bucci wrote:
> 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.
>
>
>
> On Tue, Dec 15, 2015 at 1:25 PM, Aaron Seib <aaron.seib at nate-trust.org
> <mailto:aaron.seib at nate-trust.org>> wrote:
>
> “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) and or the consumer *may* elect to
> leverage one operated by the Resource owner.”
>
> I think that answers the question of ownership.
>
> 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.
>
> 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.
>
> 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_1 , the enterprise that has your physical therapy
> records the URL for AS_2 and the PCP you have seen since you lived
> at home with your mom is still using AS_3 .
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> <http://nate-trust.org>
>
> *From:*Eve Maler [mailto:eve.maler at forgerock.com
> <mailto:eve.maler at forgerock.com>]
> *Sent:* Tuesday, December 15, 2015 12:38 PM
> *To:* Aaron Seib
> *Cc:* openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
>
>
> *Subject:* Re: [Openid-specs-heart] The Number and Ownership of
> Authorization Servers.
>
> Eliding old text below to make the thread shorter...
>
> 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).
>
> *build:* 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.
>
> *buy:* 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.
>
> *outsource:* Alice could survey the available AS SaaS services on
> the market and choose one.
>
> Adrian's HIE of One open-source project makes some of the above
> scenarios possible.
>
> 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!)
>
> *Eve Maler
> *ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl |
> Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/>
> community!
>
> On Tue, Dec 15, 2015 at 9:25 AM, Aaron Seib
> <aaron.seib at nate-trust.org <mailto:aaron.seib at nate-trust.org>> wrote:
>
> 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…
>
> *Support independent authorization services and identity
> providers, to be chosen by people who may build, run, or outsource
> these services.*
>
> Support is clear to me – it implies that it should allow for so
> the first word I am good with.
>
> What is meant by an *independent* 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)?
>
> 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.
>
> 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’.
>
> 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.”
>
> 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?
>
> 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?
>
> 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?
>
> *From:*Eve Maler [mailto:eve.maler at forgerock.com
> <mailto:eve.maler at forgerock.com>]
> *Sent:* Tuesday, December 15, 2015 11:24 AM
> *To:* Aaron Seib
> *Cc:* Adrian Gropper; Crandall, Glen;
> openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
>
>
> *Subject:* Re: [Openid-specs-heart] The Number and Ownership of
> Authorization Servers.
>
> Actually, what's in our charter related to number/ownership/trust
> around (UMA) authorization servers would probably be these
> passages <http://openid.net/wg/heart/charter/>:
>
> * "The following efforts are out of scope: ... Development of
> related *trust frameworks*."
> * (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/*trusted* 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."
> * "The specifications must meet the following basic
> requirements, in addition to specific use cases and
> requirements later identified by this Working Group: ...
> *Support independent authorization services and identity
> providers, to be chosen by people who may build, run, or
> outsource these services.*"
>
> 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.
>
> 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.
>
> *Eve Maler
> *ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl |
> Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/>
> community!
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date:
> 12/14/15
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> <mailto:Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/3ee62d35/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/3ee62d35/attachment-0001.jpe>
More information about the Openid-specs-heart
mailing list