[Openid-specs-heart] HEART Scopes & Resource Sets

[Eve Maler]

I love waking up to so much substantive discussion. :-) A couple of
comments:

*First, obligations.* Using XACML-style P*P terminology, the UMA model of
access control (using the default "bearer" token profile) approximates a
"PDP" (the authorization server) populating the access token with
obligations (scoped permissions tied to resource sets) that the "PEP" (the
resource server) is expected to adhere to in the context of a trust
relationship (e.g., an access federation trust framework). If the RS and AS
are run by the same organization (as is typical in vanilla OAuth
deployments), the trust is very tightly bound, while in UMA, the two might
be part of a wide ecosystem, where trust establishment is forged
explicitly, with the resource owner's consent, and recorded through --
presto -- an embedded instance of OAuth.

*Second, boiling a cup of tea.* If using the existing SMART-defined scopes
makes sense for OAuth because they align with security tags and so on,
great. I think Justin hit the nail on the head on Monday observing that UMA
is strictly more expressive than OAuth, and we don't have a lot of "best
practices" yet to refer to in mapping OAuth scopes to UMA resource sets and
scopes, so I'd like to examine the right conceptual way of leveraging UMA's
capability of making resource sets explicit, so as to ensure that
policy-setting (handling consent directives) can be as rich as it needs to
be -- something that today's OAuth experience doesn't really inform us about

Constraining Purpose-of-Use is another potential dimension. There are a
couple of ways to do this. One, originally suggested by Dazza Greenwood,
was to standardize scope definitions with (effectively) terms of use in
them. This binds Purpose-of-Use 1:1 with scopes and also provides a
"notice" model for the requesting party, so it might be too inflexible, but
it also has some attractions. Another, as proposed by the UMA group in its
early "claims" work, is to require the requesting party to provide a claim
that serves as a promise to adhere to a standardized purpose constraint.
This provides a "consent" model, and can be done orthogonally to scopes
(and also resource sets), for x:y:z flexibility (e.g., you can have the
Allergy record, but only for Viewing, and for TPO but not for Marketing
purposes).


*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 Wed, Jun 17, 2015 at 5:51 AM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> I use that phrase because we need to take steps and not try to solve
> everything in one step; just boil a cup-of-tea, not the whole ocean. In the
> early phases we will NOT be using everything possible. In the early phases
> we should pick the highest value, least complex, step. If we try to use the
> whole complexity of the Healthcare Policy space we will never get anywhere.
> Yet if we choose stepping-stones that get us further than we are, and in
> the right direction, we will eventually get there.
>
>
>
> This is why I do recommend we simply take on the SMART defined scopes.
> They are not the final scopes, but they get us further than we are now. We
> could argue about scopes endlessly and never get anywhere. Or we can choose
> to take a step forward, and learn something.
>
>
>
> This is why I recommend on the security-tags front, that we have the PDP
> use them as PIP, and not expect to use them on the PEP side. Use OAuth
> mechanisms for Obligations, or not have Obligations at all in our first
> step. Obligations can often be pushed into policy – Trust Framework --. For
> example: an obligation such no-redisclosure-without-consent can be easily
> enforced by policy, often more completely than trying to enforce that by
> technology.
>
>
>
> This is why I recommend we choose simple consents, that get us beyond
> stupid-consents, but don’t yet get us to full blown. Build a system that is
> extensible, and extensible in a way that today seems like it will work.
>
>
>
> by the time we get to tomorrow the problem space looks different anyway.
>
>
>
> In a word… Agile…
>
>
>
> John
>
>
>
> *From:* Debbie Bucci [mailto:debbucci at gmail.com]
> *Sent:* Wednesday, June 17, 2015 7:41 AM
> *To:* Moehrke, John (GE Healthcare)
> *Cc:* openid-specs-heart at lists.openid.net; Eve Maler
> *Subject:* RE: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
> I need to start doing some homework ....
>
> Use or not ...I think that is the crux of the issue..
>
> On Jun 17, 2015 8:37 AM, "Moehrke, John (GE Healthcare)" <
> John.Moehrke at med.ge.com> wrote:
>
> Debbie,
>
>
>
> You ask “If FHIR resources/attributes are being used for the PIP - are
> they being used for enforcement (PEP) as well”.
>
>
>
> Not as simple to answer… but the same first answer that I gave to the DS4P
> tagging… there are Obligations there for us to use, or not.
>
>
>
> Background… The Policy Enforcement Point is the place where a Decision
> will be Enforced. So the enforcement is simply enforcing a decision. The
> decision is based on policy, and possibly PIP that are inclusive of FHIR
> resources/attributes.
>
>
>
> However within the DS4P/HCS tags from HL7, the FHIR security-tags that I
> talked of in the previous email, there are a set of these vocabulary that
> are Obligations. In some Access Control architectures the obligations are
> part of the access control Decision, output of PDP.  The expectation is
> that the PEP will carry out those obligations (expectation proven by
> trust-frameworks). In other cases these Obligations are representation of
> persistent policy and thus are input to PIP, not output of PDP.
>
>
>
> So they are there, we could use them, or not…
>
>
>
> My understanding, please correct me if I am wrong, is that UMA/OAuth have
> their own mechanism for carrying Decision based Obligations to be
> Enforced…  If this is true then we likely don’t want to confuse things with
> two ways to carry Decisions.
>
>
>
> Note that this doesn’t make the Obligations in FHIR useless, as FHIR has
> many transports, it is not restricted to HTTP REST. So in the other
> transports the Obligations are still useful.
>
>
>
> PS, there is also a set of vocabulary for Purpose-Of-Use: Treatment,
> Payment, Research, etc…
>
>
>
> PPS, there is an emerging vocabulary, that is not very mature, for medical
> Roles: Doctor, Nurse, Radiologist, Dietician, Patient, Guardian, etc…
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Moehrke, John
> (GE Healthcare)
> *Sent:* Wednesday, June 17, 2015 7:03 AM
> *To:* Debbie Bucci; Eve Maler
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
> Debbie,
>
>
>
> The DS4P tagging is baked right into the FHIR spec… so it is there for us
> to use (or not).
>
>
>
> For others, what this means is that all FHIR resources have a common
> header (was external HTTP based metadata originally, but now inside the
> resource at the top). This common header has a well-known place for
> ‘security-tags’, and a recommended vocabulary for use. This vocabulary is
> made up of a set of vocabulary designed over the years in HL7 (and other
> healthcare standards): Sensitivity classifications (the kinds of medical
> data that have specific sensitivity or regulated behavior), Confidentiality
> classification (privacy risk rating on a scale), Obligations, Compartments,
> and Integrity classifications. This is an extendable vocabulary so capable
> of more.
>
>
> http://healthcaresecprivacy.blogspot.com/2013/09/hl7-ballot-healthcare-securityprivacy.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__healthcaresecprivacy.blogspot.com_2013_09_hl7-2Dballot-2Dhealthcare-2Dsecurityprivacy.html&d=AwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BE3LqvnVgeEYoN2wBfwhL8VTwzhV4Ji-P5CblEnofI0&s=eK8IIpVW0htMXgd1HSsQtCltxuZzOhU_54kN2Clz9cc&e=>
>
>
>
> This vocabulary was the focal point for “Privacy on FHIR” demonstrations,
> along with consent.
>
>
> http://healthcaresecprivacy.blogspot.com/2013/10/fhir-demonstration-of-ds4p.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__healthcaresecprivacy.blogspot.com_2013_10_fhir-2Ddemonstration-2Dof-2Dds4p.html&d=AwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BE3LqvnVgeEYoN2wBfwhL8VTwzhV4Ji-P5CblEnofI0&s=Vt0k1GdqlvBE7v-gnJgawRTiEb-X8p_qnCiGL36jbH8&e=>
>
>
>
> It is important to note that this metadata tagging system is there to be
> used. It is not magically filled out, nor magically used. So it is
> important to both set it correctly (where there have been a few
> demonstrations of how to automate this), and use it during enforcement.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Debbie Bucci
> *Sent:* Wednesday, June 17, 2015 5:03 AM
> *To:* Eve Maler
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
>  This thread is touching on everything that I thought it would  ...
>
>  I am going to boil this down to the internal conversation we had over the
> weekend -
>
> A. FHIR scope interop between OAUTH/UMA
> B. Current gap (perhaps in both specs!) that is leaning towards  or could
> inform UMA extension
> C.  Overarching access control/ABAC conversation   - that John seems to
> have touch upon.   I have a whole bunch of questions there ... If FHIR
> resources/attributes are being used for the PIP - are they being used for
> enforcement (PEP) as well - is DS4P like FHIR tagging on the table?  Will
> vendors implement? ... (no need to answer just throwing them out there )
>
> If we will focus on A .. that should inform B  - but others are interested
> - perhaps and entirely different thread/conversation  is needed for C
>
> In re: to vectors -- consent related -  sensitive health topics and
> delegation are two areas I believe are relevant for this WG.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jun 16, 2015 at 2:06 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
> Hi Thomas-- Delegation in this sense (actively choosing to assign
> authorization rights to someone else) is something I'm working on a lot
> lately. ("Delegation" is a word with a lot of meanings, sigh.) Obviously,
> Alice-to-Bob sharing is supposed to be a key UMA benefit.
>
>
>
> I think you're using "scope" in an odd sense by talking about "creating a
> new scope for Bob". It's more like a policy in that case, or a policy
> template or something. Or maybe you're suggesting that, through family
> relationships, there's a kind of role basis for sharing ("mother-daughter")
> that determines policy workflow, and when Bob differs enough from a
> standard role, you have to peel him away from it. (Though God help us if we
> replicate RBAC for ordinary consumers and patients. It doesn't even scale
> in the enterprise.)
>
>
>
> As for propagation, this may be a bit far afield for the main topic under
> discussion in this thread, but for those who are interested, I see some
> huge potential for how to drive layers of sharing policy off of graph
> technology. (My colleagues recently did a forward-looking demo
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3D-2DBAyu4KuSOI-26index-3D8-26list-3DPLK58Vrtd56-2DU4YkavFo0DR1yFpkw9G-5Flm&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=yf0AGqugbRYOrut9NkwbXs1TyQyjg7GqHlNc4AIrLZ4&e=>
> of graph-driven policy with an IoT bent (24:00).)
>
>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=u2vKFCtEm_0Q_5jC4K8Lq9pHWid6xUihJqDLbOz7O4w&e=>
> community!
>
>
>
> On Tue, Jun 16, 2015 at 8:42 AM, Thomas Hardjono <hardjono at mit.edu> wrote:
>
>
> Folks,
>
> Sorry for having been absent for a while.
>
> >>> Eve:
> >>> In discussions with consumer IoT folks, it
> >>> seems that smart light bulbs want to be
> >>> gathered by "room".
>
> So this is the second time in two weeks that I've heard discussions about
> resources/scopes and OAuth2.0 (the other venue was related to IoT).
>
> (1) One of the problems with grouping resources (what we call "resource
> sets" here) is that there are always cases where there is an exception to
> the access being granted. For example, Alice has created a "resource set"
> called "lighting in the house". She wants to grant Bob (the electrician)
> access to this resource set with the exception of lighting in the kitchen,
> say. So the access control logic has to be able to handle this
> semantically. If there too many exceptions to the resource-set scope, then
> you may as well create a new scope just for Bob.
>
> (2) Relationships as a "resource" or "scope":  Should relationships be
> expressed as a resource or scope (or both/neither)? So in Josh's example,
> Alice and her Mom have a relationship that allows Mom to say "I grant my
> daughter permission to read my Med files". Not to get theoretical, but what
> if Alice has a sister Cathy who also qualifies as "daughter-of".
>
>
> I'm not sure if the OAuth WG ever addressed these issues, but in the UMA
> WG we really haven't addressed them sufficiently (too busy getting UMA core
> 1.0 finished). We also haven't addressed the issue of delegation and
> propagation of delegated rights.
>
> /thomas/
>
>
> ____________________________________________
>
>
> From: Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
> Sent: Tuesday, June 16, 2015 10:42 AM
> To: Eve Maler
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
> Eve,
>
> The main difference is that it’s not at all uncommon in the OAuth world to
> ask for authorization to multiple resources protected by the same AS
> simultaneously. In fact, this is seen as a *feature* of the OAuth approach,
> since it’s lower decision overhead for the user (when done right). In that
> case, if a client asks for “read write delete” scopes of an AS, the AS
> still needs to know *what* those scopes apply to. Since OAuth doesn’t have
> any type of resource or audience identifier (a big hole in the spec), this
> gap has been usually filled by having a scope identify the resource. Note
> that this is still semantically sensible and doesn’t go against what
> “scope” is defined as.
>
> This is where you get the matrix definition. You’ve got some scopes that
> mean “where can I do things” and others that mean “what can I do there”. I
> think Josh’s approach of “what.where” is reasonable given this technical
> constraint, and not without precedent. As far as the AS is concerned, it’s
> dealing with just strings from the client, but it can still easily make the
> UX of the authorization page a little smart based on the understood
> semantics of these well-defined scopes.
>
>  — Justin
>
> On Jun 15, 2015, at 7:44 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>
> Hi Josh-- Below...
>
>
> 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 community!
>
> On Mon, Jun 15, 2015 at 2:24 PM, Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu> wrote:
> Hi all,
>
> I didn't mean to take a hard-line position on today's call about scope
> definitions! To my mind, our approach to scopes will need to work
> hand-in-hand with our approach to endpoint (or resource set) discovery --
> so I feel a bit awkward discussing scopes here in isolation. But that said,
> let me see if I can at least highlight the tension that we heard in the
> past hour's discussion (in a neutral way):
>
> ---
> Goal: Whatever the model, we want to support a use case where Alice signs
> into her resource server and can set some policies in an intuitive way.
> |She'd see something like (very, very roughly):
>
>  My Medications:
>  * Who can view?
>  * Who can write new prescriptions?
>
> My Step Counts
>  * Who can view?
>  * Who can remove?
> ---
>
> The question is about how this works under the hood.  I think we were
> discussing two models:
>
> Model 1: The "UMA-First" approach
> We have a resource set like "Alice's Medications", with scopes like "view"
> and "prescribe". And we'd have a resource set like "Alice's Step Counts"
> with scopes like "view" and "delete".
>
> Model 2: The "OAuth-First" approach
> We have a resource set like "Alice's FHIR Endpoint", with scopes like
> "Medications.view", "Medications.prescribe", "Steps.view", and
> "Steps.delete".
>
>
> Talking about an "OAuth-first" approach for setting policies is making me
> confused. I know what it looks like to enable OAuth-like flows in UMA when
> Alice is both the requesting party and the owner of the resource. And I
> know what it looks like to enable Alice to set policies at an UMA
> authorization server (which might hold the results of a previous OAuth-like
> flow done in UMA). But I don't know what "setting policies in OAuth" means
> because the OAuth experience is about consenting at run time (possibly
> checking and unchecking individual scopes), and revoking tokens at the
> AS/RS.
>
> So the closest UX analog would probably be the wording displayed in an
> OAuth consent dialog, maybe something like:
> • View [and prescribe] your medications
> • View [and delete] your steps
>
> If the *types* of Resource Sets and the allowed scopes are standardized in
> advance (which UMA supports), then a mapping between Model 1 and "vanilla"
> OAuth could be as simple as: "concatenate the UMA resource set type
> followed by ':' followed by the UMA scope name" -- so for example, you
> might derive an OAuth scope like "
> https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_resource-2Dtypes_StepCounts-3Ahttps-3A__openid.net_heart_scopes_view&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=NY3dpaK6jL3Yfkv9k_f1AhXAK9Mlwlr3Xx0bfjqEfg4&e=>".
> Or under Model 2, the scopes could be reused directly (no mapping required).
>
> In what sense is "reuse" meant here? A coding model, or an architectural
> model, or a semantic model?... There are ways in which I could imagine a
> deep kind of semantic reuse being possible without concatenation tricks
> being necessary. However, not being a developer, I'm not sure if they match
> what you're thinking of.
>
> For example, in my previous response to the minutes email, I outlined how
> some APIs have implicit mappings between scopes and acceptable
> endpoints/resources to which they apply.
>
> Let's say (totally making this up) the FHIR has two endpoints, with one
> endpoint for medication records and one for fitness steps. There's an
> UMA-standardized resource type for each. There's "
> https://www.hl7.org/fhir/rsrc/med.json
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_med.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=l-4qDmb2SMKJH01dMJA_TKP5MkEC8qec3Gg1MtrWFR4&e=>",
> with instances of it registered with scopes "view", "download", "transmit",
> and "add" (so some clients can insert new entries). Alice's medications
> might be in a resource something like "/alice/meds". (What's displayed in
> her AS dashboard might look a lot nicer than that.) And there's "
> https://www.hl7.org/fhir/rsrc/step.json
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_step.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=hEoZNPfmvLWm9VIAsdMIejdA0UrXhuHUuU30Z3Oqx68&e=>",
> with instances of it registered with scopes "view", "download", "transmit",
> and "chart". Alice's steps might be in a resource like "/alice/steps".
>
> (If the scopes are in the form of URIs, they could be standardized to a
> further degree, in that a bunch of metadata could be pulled by the
> authorization server and used to present standard labels and icons, and
> other semantics could be linked to them.)
>
> If the very same API were OAuth-protected, with the very same resource
> endpoints, there might still be the same resource endpoints, with the same
> scopes, where three of them work on both resource types, "add" only works
> on "med", and "chart" only works on "step". These resources could still
> have a standardized meaning in terms of both resource naming and
> schema/format; there just would be nowhere to "hook" a standardized
> resource type URI into.
>
> Seen this way, the OAuth approach and the UMA approach are quite similar,
> differing only in the implicitness vs. explicitness of the resource set
> layer.
>
>
> Of course, some interesting things happen when we layer in details like...
>
> What if Alice has access to multiple records (say, her own and her
> mother's)? In vanilla OAuth the binding of permissions to these records is
> generally implicit. How should they play out in UMA? Under Model 1, we'd
> probably see two more Resource Sets created ("Alice's Mom's Medications"
> and "Alice's Mom's Steps"). Under Model 2, we'd probably see one more
> Resource Set created ("Alice's Mom's FHIR Endpoint").
>
> I've been doing some work around chained delegation of this sort. Indeed,
> these are separate records, and must remain that way. Alice may not have
> all the permissions over her mother's records that she has over her own!
> One way to present such "downstream" items is to present them under a
> separate "Shared With" area. And there are various ways to organize owned
> items, e.g. by who you tend to share them with or by function. In
> discussions with consumer IoT folks, it seems that smart light bulbs want
> to be gathered by "room".
>
> FWIW...
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=BCXN2yJjroCBMUqvmYU1tP4OOtnfZvpRN0B5JObGnLA&e=>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=BCXN2yJjroCBMUqvmYU1tP4OOtnfZvpRN0B5JObGnLA&e=>
>
>
>
> _______________________________________________
> 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/20150617/dc3273c9/attachment-0001.html>