<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
> So ... seems to me that client flows could (would) be designed
differently anyway based on whether Bob or Alice is making the
request. <br>
<br>
Exactly: how is the client supposed to know that it's representing
Alice or Bob? You'd expect a software client to be able to speak to
an API and have a fairly clear path on how to fulfill its security
obligations. Unfortunately, there's no "is_alice" flag in the
protocol stack that we can count on. :) <br>
<br>
An UMA client needs to be able to be pointed to an AS, take in a
ticket (as a JSON value, regardless of what encoding the API it's
speaking to uses), talk to the "requesting party" endpoint to trade
the ticket for a token, and then it needs to be able to gather the
claims that the AS gives it hints for. As Eve keeps pointing out,
those claims could be absolutely anything, fulfilled by the client
or by someone else or just because it's Tuesday, so the client is
really going to need to be written to a very specific profile of UMA
for it to have any chance of doing something useful. Then it needs
to come back with the ticket, again, and try to get a token,
potentially repeating the claims gathering cycle if it guessed wrong
on the last step. <br>
<br>
Exactly *none* of these actions are required for an OAuth client.
The wire protocol is a very, very different thing, and the code
paths are almost completely separate with OAuth 2.0 and UMA 1.0. <br>
<br>
This is to say nothing of the differences in the protected resource,
which is also pretty substantial. It's very, very difficult to write
something to be protected by both OAuth and UMA simultaneously
without very careful delineation of how that's to happen.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 7/12/2015 11:16 AM, Debbie Bucci
wrote:<br>
</div>
<blockquote
cite="mid:CAG6zQ1ZY1HEQhU_sYUbGOyNH0frkZ28SEXXmcEyMc8QOFin31A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>
<div>
<div>To answer the reverse - I'd like to better understand:<br>
<br>
</div>
ATT interactions and dependencies - . asynchronous
authorizations and on the wire or calculus that happens -
flow is different get that ...<br>
</div>
PAT - how that aligns/replaces/supplements the traditional
Access Control (PIP, PEP ABAC/RBAC) stuff most likely will
be required - <br>
</div>
OAuth 2.0 likeness ... I don't necessarily see where there will
be an entirely different rewrite. Example: - authentications
may be assumed via a standard OAUTH flow - yet some
implementations will choose to add the additional id_token
(OIDC). If an RPT token is handled programatically as an
access token ...what has to change? So ... seems to me that
client flows could (would) be designed differently anyway based
on whether Bob or Alice is making the request. <br>
<br>
<br>
<div><br>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jul 9, 2015 at 12:55 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 link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If
you get a life be sure to leave a bread crumb trail
so the rest of us can follow you out.</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">Aaron</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"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib, CEO</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o)
<a moz-do-not-send="true" href="tel:301-540-2311"
value="+13015402311" target="_blank">301-540-2311</a></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a moz-do-not-send="true" href="tel:301-326-6843"
value="+13013266843" target="_blank">301-326-6843</a></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="http://nate-trust.org" target="_blank"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img
src="cid:part4.03000608.04070008@mit.edu"
border="0" height="48" width="205"></span></a><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"><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"">
Openid-specs-heart [mailto:<a moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Eve Maler<br>
<b>Sent:</b> Thursday, July 09, 2015 11:18 AM<br>
<b>To:</b> Moehrke, John (GE Healthcare)</span></p>
<div>
<div class="h5"><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><br>
<b>Subject:</b> Re: [Openid-specs-heart] Flip the
question of “Vanilla" OAuth vs. UMA</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">John, no doubt you're 200%
overbooked, but if we could attract you to the
UMA meetings, you'd probably find our current
workstream fascinating. :-) The Kantara
Leadership Council members laugh at me for
getting excited about the "BLT sandwich"
(business-legal-technical) progress updates I
give them... We are literally mapping specific
bits of UMA flows to the norms of sociotechnical
systems being identified in cutting-edge
academic research.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Then again, maybe I need to
get a life. </p>
</div>
</div>
<div>
<p class="MsoNormal"><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"> </p>
<div>
<p class="MsoNormal">On Thu, Jul 9, 2015 at 8:07
AM, Moehrke, John (GE Healthcare) <<a
moz-do-not-send="true"
href="mailto:John.Moehrke@med.ge.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a></a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Eve,</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">You
are right on… </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">As
one of the co-chairs of the HL7 Security
wg, I have struggled with this. However
in Healthcare we must keep moving
forward. So the work in HL7 is to
incrementally improve the ability to
capture anything we can related to the
act of consent, and the meaning of that
consent. We recognize these as difficult
domains. Historic precedent in
healthcare is embarrassing.</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">In
HL7 we have two different encodings. One
is based on the format of a document
used for all other medical-fact
documentation (CDA). The format is not
important, but it is important to
indicate that it is a form that
healthcare handles for almost everything
related to the patient, so it is easy
for them to handle it for this purpose
too. It is a form however that is
totally foreign to any access control
decision system. We thus recognize that
the rules might be ‘equivalently’
encoded in some access control decision
language (common is XACML today). The
equivalency is left to humans to agree…
Thus the bridging of the divide between
them is not computable, but we are
trying.</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
HL7 FHIR effort is just getting going,
and for the most part will start with
the same capability, just with different
technical encoding. Still not
necessarily fixing the big issue… But
getting more processable (FHIR is
predominantly HTTP/REST and encodes
things in more simple XML or JSON; where
as CDA is ugly XML).</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
actual systems-design might have the
Access Control rules interjected at the
time that the patient gives consent; or
might interpret the consent at the time
of needing to make a decision. This is a
systems-design responsibility that is
not the role of HL7. There are good
reasons to do either, especially since
healthcare is a lifelong effort (so we
think in 100+ years).</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">So,
look to HL7 to help with capturing the
ceremony of Consent. But they definitely
need help with the Enforcement, we hope
HEART can help with. AND we all need to
work on everything in-between.</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">John</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"">
Openid-specs-heart [mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a></a>]
<b>On Behalf Of </b>Eve Maler<br>
<b>Sent:</b> Thursday, July 09, 2015
9:47 AM<br>
<b>To:</b> Kinsley, William<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>
<p class="MsoNormal"><br>
<b>Subject:</b> Re:
[Openid-specs-heart] Flip the question
of “Vanilla" OAuth vs. UMA</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Hi Bill-- I'm not
sure what the HL7 consent/contract
standards are about, but based on
what I know of "notice and consent"
(privacy) theory, and "contract"
(legal) theory (IANAL but I have
collected lawyers for many years as
part of my UMA work), there is not
very much in the technical
underpinnings of almost any
technical or machine-readable
consent flow used on the web today,
to support a true non-adhesion
contract for Alice. (Perhaps the
closest thing on the OAuth side
would be requiring an OAuth scope
unchecking facility, but that's
still not a formal mapping to a
contract model -- has someone done
that mapping?)</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">In the UMA
group, with the help of Tim
Reiniger (the primary drafter of
the new Virginia digital identity
law), we have recently started
applying a "license" vs. a
"contract" paradigm to the UMA
flows. In fact, we're planning to
discuss this on today's UMA call
in a little over an hour.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I may be on the
wrong track here, but this is what
your note put me in mind of...</p>
</div>
</div>
<div>
<p class="MsoNormal"><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="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e="
target="_blank">ForgeRock.org
OpenUMA</a> community!</p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Wed, Jul 8,
2015 at 8:08 AM, Kinsley, William
<<a moz-do-not-send="true"
href="mailto:BKinsley@nextgen.com"
target="_blank">BKinsley@nextgen.com</a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">I
need Eva to verify that what
I am saying is correct, I am
still coming up to speed on
UMA … HL7 has/is developing
FHIR consent(contract)
standards and I believe the
oAuth and UMA profiles are
in scope to support these
and possibly others. </span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">To
easily support
interoperability, is it
possible (or in scope) to
develop profile standards or
profile taxonomy that would
be flexible and adaptable so
that the RS would be able to
process FHIR consents even
if they are modified by a
specific implementation
without special coding.
This could be too
idealistic, out of scope or
just not supportable with
oAuth and/or UMA profiles. </span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">For
example: A client could
connect to any FHIR resource
and process any Heart
Profile that is provided,
even if the client is
another RS running in a
“Client” role to another RS
.</span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">Bill</span></p>
<p class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
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, July
07, 2015 10:00 PM<br>
<b>To:</b> Aaron Seib<br>
<b>Cc:</b> Kinsley, William;
<a moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re:
[Openid-specs-heart] Flip
the question of “Vanilla"
OAuth vs. UMA</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Commenting
on one of Aaron's
bulleted items:</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Profiling
"a standard way to
label assets managed
by the RS" is one of
the tasks I was
contemplating to be
potentially in scope
for our semantic UMA
profile. This is
because it is possible
for resource set
descriptions (these
are things that an UMA
RS registers at an AS,
to put resources under
protection) to include
resource types. As I
understand it, the
FHIR API conveys data
structures that
reflect quite a lot of
HL7 standardization
work already done,
which amounts to
"resource typing".</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">While
a lot of companies
with proprietary APIs
might not want to
standardize their
resource assets,
there's a lot of power
in standardized
resource labeling in
open ecosystems like
the one we're working
on. For starters,
there's a <a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.kantarainitiative.org_uma_rec-2Doauth-2Dresource-2Dreg-2Dv1-5F0.html-23rfc.section.4&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=XZvNdZZ9gPcuIcTPhPiiE_QBSahOHLBvTzItUZRdivI&e="
target="_blank">security
consideration</a> that
is mitigated by the
use of "well-known and
standardized"
description elements.
(See this <a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xmlgrrl_UMA-2DSpecifications_issues_151&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=71o1AnmsYBp0TU9vvpx_TuaYsMN1txaagwxyDCElFnc&e="
target="_blank">UMA
issue</a> for some
background.) For
another example,
standard types could
drive automated policy
workflows in
interesting ways.</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><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="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e="
target="_blank">ForgeRock.org OpenUMA</a> community!</p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On
Tue, Jul 7, 2015 at
2:56 PM, 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>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks
for starting
this new
thread.</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 not expert
in this space
(yet) but let
me see if I
can repeat
back what I
think you are
proposing. </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">Are
you suggesting
that for
Resource
Server (RS) be
able to accept
a standard
profile
authorization
assertion
(based on the
UMA profile)
from a
standard
(UMA-based)
Authorization
Server (AS)?
</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
maybe out of
date but I
seem to
remember
reading that
the UMA
profile states
that the
Authorization
Policy service
capabilities
(as required
to implement
an AS) are out
of scope for
the UMA
profile - as
are the
specific
policies for
how you label
assets
(network,
applications,
data) managed
by the RS with
access tokens
that are
registered
with and
managed by the
AS. </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">To
echo back your
language is
your
suggestion
that </span><span
style="font-size:14.0pt;font-family:"Cambria","serif";background:yellow">it</span><span
style="font-size:14.0pt;font-family:"Cambria","serif"">
^would^ <span
style="background:yellow">be simpler to have consistent patterns
(libraries)
implemented</span></span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
that would
address what
the UMA
profile has
intentionally
said is out of
scope? I.e.,
</span></p>
<p><span
style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span
style="font-size:7.0pt;color:#1f497d"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">addressing
the need for a
standard way
to label
assets managed
by the RS; and
(?) </span></p>
<p><span
style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span
style="font-size:7.0pt;color:#1f497d"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">a
standard way
to represent
the inputs to
an
Authorization
Policy Service</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">In
my mind this
would allow us
to not only
solve the
simple cases
but also
enable us to
develop
libraries that
represent the
applicable
policy of a
given Federal
Reg or
libraries of
applicable
state law that
could be
re-used by
everyone. It
might also
enable the
different
associations
to provide
recommended
policies to be
adopted by
their members
and plugged
into the
solution
following a
period of
local policy
tweaking by a
given
institution or
Agency.</span></p>
<p
class="MsoNormal"
style="margin-left:.5in"><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">Am
I getting this
right?</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib, CEO</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton
</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o)
<a
moz-do-not-send="true"
href="tel:301-540-2311" target="_blank">301-540-2311</a></span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a
moz-do-not-send="true"
href="tel:301-326-6843" target="_blank">301-326-6843</a></span></p>
<p
class="MsoNormal"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=tPRDdAyGDknsaFwvwbIPyKu9NkZpJ-UX0L62WfJTfPk&e="
target="_blank"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img
src="cid:part25.00020000.06050300@mit.edu" border="0" height="48"
width="205"></span></a></p>
</div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df
1.0pt;padding:3.0pt
0in 0in 0in">
<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"">
Openid-specs-heart
[mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a></a>]
<b>On Behalf
Of </b>Kinsley,
William<br>
<b>Sent:</b>
Monday, July
06, 2015 8:45
PM<br>
<b>To:</b> <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><br>
<b>Subject:</b>
[Openid-specs-heart]
Flip the
question of
“Vanilla"
OAuth vs. UMA</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif"">I
am starting a
new thread …
I think we
need to flip
the question
of “Vanilla"
OAuth vs.
UMA”. I feel
confident that
we are going
to discover
use cases that
cannot be
supported by
“Vanilla”
OAuth or would
be greatly
simplified by
using UMA. </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif""> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif"">Maybe
the real
question to
ask is: Are
there any
augments (use
case,
technology
restriction,
cost, etc.)
that justifies
NOT using
(requiring)
UMA?</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif""> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif"">From
a
interoperability,
quality,
security and
development
perspective,
would it be
simpler to
have
consistent
patterns
(libraries)
implemented
that are more
likely to be
“drop-in
compatible”
without source
changes. While
the standard
itself would
be considered
rigid, it
would be
flexible by
the use and
implementation
of the UMA
profiles.
</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif""> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif"">The
caveat here is
the resource
server (RS)
would need to
be able to
accept/process
a UMA profile
without
developing
custom code to
interpret it.
Would this
require
resource
servers to
adhere to a
standard set
of UMA
profiles or a
defined UMA
profile
taxonomy that
could describe
the healthcare
consent models
(if one
exists)?</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif"">Bill</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span></p>
</div>
<div
style="margin-top:6.7pt;margin-bottom:6.7pt">
<p
class="MsoNormal"><span
style="font-family:"Arial","sans-serif""> </span></p>
</div>
<table
style="width:670.45pt;margin-left:5.4pt"
border="0"
cellpadding="0"
cellspacing="3" width="1117">
<tbody>
<tr
style="height:26.25pt">
<td
style="padding:.75pt
.75pt .75pt
.75pt;height:26.25pt">
<p
class="MsoNormal"
style="margin-bottom:6.7pt;text-align:right" align="right"><span
style="font-family:"Arial","sans-serif""> </span></p>
</td>
<td
style="padding:.75pt
.75pt .75pt
.75pt;height:26.25pt"><br>
</td>
</tr>
</tbody>
</table>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif""> </span></p>
<table
style="width:670.45pt;margin-left:5.4pt"
border="0"
cellpadding="0"
cellspacing="3" width="1117">
<tbody>
<tr>
<td
style="padding:.75pt
9.85pt .75pt
9.85pt"><br>
</td>
</tr>
</tbody>
</table>
<p
class="MsoNormal"><span
style="font-size:14.0pt;font-family:"Cambria","serif""> </span></p>
</div>
</div>
<table
style="width:670.45pt;margin-left:5.4pt"
border="0"
cellpadding="0"
cellspacing="3"
width="1117">
<tbody>
<tr>
<td
style="padding:.75pt
.75pt .75pt
.75pt">
<p
class="MsoNormal"
style="margin-bottom:6.7pt"><b><span
style="font-size:10.0pt;font-family:"Calibri","sans-serif"">William
Kinsley<br>
</span></b><span
style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Enterprise
Architect,
Ambulatory</span></p>
<div>
<p
class="MsoNormal"
style="margin-bottom:6.7pt"><b><span
style="font-size:10.0pt;font-family:"Calibri","sans-serif"">NEXTGEN
HEALTHCARE<br>
</span></b><span
style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Solutions
for:
Ambulatory,
Inpatient and
Community
Connectivity<br>
795 Horsham
Road, Horsham,
PA 19044<br>
<a
moz-do-not-send="true"
href="tel:%28215%29%20657-7010%20x21128" target="_blank">(215) 657-7010
x21128</a>
[o] <br>
<a
moz-do-not-send="true"
href="mailto:BKinsley@nextgen.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:BKinsley@nextgen.com">BKinsley@nextgen.com</a></a></span></p>
</div>
</td>
<td
style="padding:.75pt
.75pt .75pt
.75pt"><br>
</td>
</tr>
</tbody>
</table>
<div
style="margin-top:6.7pt;margin-bottom:6.7pt">
<p
class="MsoNormal"><span
style="font-family:"Arial","sans-serif""><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span></p>
</div>
<table
style="width:487.5pt;margin-left:5.4pt"
border="0"
cellpadding="0"
cellspacing="3"
width="813">
<tbody>
<tr>
<td
style="padding:.75pt
.75pt .75pt
.75pt">
<p
class="MsoNormal"
style="margin-bottom:6.7pt"><b><i><span
style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:#e46c0a"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:#e46c0a;text-decoration:none">Be
ready for MU
and ICD-10 in
2015. Start
your EHR
version 5.8
and KBM
version 8.3
upgrade today.
Get the
resources you
need at </span><span
style="color:#007cb9"><a class="moz-txt-link-abbreviated" href="http://www.nextgen.com/upgradecentral">www.nextgen.com/upgradecentral</a></span></a></span></i></b></p>
</td>
</tr>
</tbody>
</table>
<div
style="margin-top:6.7pt;margin-bottom:6.7pt">
<p
class="MsoNormal"><span
style="font-family:"Arial","sans-serif""><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span></p>
</div>
<table
style="width:492.0pt;margin-left:5.4pt"
border="0"
cellpadding="0"
cellspacing="3"
width="820">
<tbody>
<tr>
<td
style="padding:.75pt
.75pt .75pt
.75pt">
<p
class="MsoNormal"
style="margin-bottom:6.7pt"><span
style="font-size:6.0pt;font-family:"Arial","sans-serif""><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:windowtext;text-decoration:none">This
message, and
any documents
attached
hereto, may
contain
confidential
or proprietary
information
intended only
for the use of
the
addressee(s)
named above or
may contain
information
that is
legally
privileged. If
you are not
the intended
addressee, or
the person
responsible
for delivering
it to the
intended
addressee, you
are hereby
notified that
reading,
disseminating,
distributing
or copying
this message
is strictly
prohibited. If
you have
received this
message by
mistake,
please
immediately
notify us by
replying to
the message
and delete the
original
message and
any copies
immediately
thereafter.
Thank you for
your
cooperation.</span></a></span></p>
</td>
</tr>
</tbody>
</table>
<div
style="margin-top:6.7pt;margin-bottom:6.7pt">
<p
class="MsoNormal"><span
style="font-family:"Arial","sans-serif""><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span></p>
</div>
<div
style="margin-top:6.7pt;margin-bottom:6.7pt">
<p
class="MsoNormal"><span
style="font-family:"Arial","sans-serif""><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span
style="color:windowtext;text-decoration:none"><br>
_______________________________________________<br>
Openid-specs-heart
mailing list<br>
</span><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><span
style="color:windowtext;text-decoration:none"><br>
</span><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></a></p>
</blockquote>
</div>
<p class="MsoNormal"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e="
target="_blank"><span
style="color:windowtext;text-decoration:none"> </span></a></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</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"
rel="noreferrer" target="_blank">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>