[Openid-specs-heart] The Number and Ownership of Authorization Servers.

Tue Dec 15 17:37:52 UTC 2015

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 | 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>
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]
> *Sent:* Tuesday, December 15, 2015 11:24 AM
> *To:* Aaron Seib
> *Cc:* Adrian Gropper; Crandall, Glen; 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 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/a393f7bc/attachment.html>