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

Tue Dec 15 18:41:24 UTC 2015

I am missing something you are saying - not trying to be obstinate.

Maybe I am being too literal.  When you say AS-agnostic what is that
supposed to mean?

To me agnostic means a person who believes that nothing is known or can be
known of the existence or nature of God or of anything beyond material
phenomena the context that the AS is running in as far as business or policy
considerations are considered given the way the word came to me from
religion class.

So when you use AS-agnostic are you saying that the Authorization server
behaves like a black box regardless of what business or policy environment
it is ran in.  All other things being equal the AS is doing what AS' are
supposed to do unencumbered by the environment in which they operate?

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen
Marshall [SRS]
Sent: Tuesday, December 15, 2015 1:22 PM
To: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] The Number and Ownership of Authorization
Servers.

Eve,

Thanks for the explanation and peeling the onion.

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.  

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.

A similar AS-agnostic pattern would apply to the other use cases.

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.

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 12:37, Eve Maler wrote:

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 <tel:%2B1%20425.345.6756>  | Skype: xmlgrrl | Twitter:
@xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/>  community!

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/79b7f783/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/79b7f783/attachment.jpg>