[Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5

Adrian Gropper agropper at healthurl.com
Thu Aug 11 18:56:51 UTC 2016 

On Thu, Aug 11, 2016 at 2:37 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:
<snip>

> Can we guarantee that any AS a consumer might want to point to won’t
> introduce a security risk just like email does today?
>
>
>
> If so I am with you.
>

Yes we can. For example, Google does not restrict what clients I allow to
connect to my person-level resources via OAuth. There is no need for HEART
to introduce a security vs. privacy compromise. UMA has to deal with this
issue, not HEART.

Adrian

>
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Thursday, August 11, 2016 12:36 PM
> *To:* Aaron Seib
> *Cc:* John Moehrke; ddecouteau; Kretz, Jim M. (SAMHSA/CMHS);
> Gonzales-Webb, Suzanne (Engility); Kathleen Connor; Johnathan Coleman
> [SRS]; Davis, John M.; HEART List; Mohammad Jafari
>
> *Subject:* Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85,
> Issue 5
>
>
>
> Aaron - I think you mostly have it. Also, Justin just made the same point.
> The RS always has the last word regardless what the AS authorizes. However,
> the RS should not be allowed to make random overrides to what the AS has
> authorized. The RS should disclose its policies for overriding the AS at
> the time the AS is registered so that the patient has a chance to walk away
> and do business with a different RS.
>
> This is pretty-much current HIPAA Notice of Privacy Practices practice. A
> patient can ask a service provider for info-related things at
> patient-enrollment time and the RS does not have to agree in which case the
> patient can go elsewhere. Once the RS and the patient have agreed on a set
> of policies, the RS cannot change their policies without updating the
> agreement with the patient.
>
> Your 42CFR example is confusing. Adherence to 42CFR is not a choice of the
> RS. The introduction of a patient-specified AS actually helps the RS
> because the AS provides authorization to share with a specific Client just
> the way 42CFR requires. This effectively indemnifies an RS subject to 42
> CFR and that's a win-win.
>
> You need to come up with a different example of a patient-level FHIR
> resource that an RS might not want to allow authorization by the patient.
> HIPAA, for example, says the RS does not have to provide patient access
> over psych notes. That means that the RS could decide that a Client
> authorized to receive psych notes is actually a stooge of the patient and
> they would be allowed under HIPAA to (a) not register psych note resources
> with the AS in the first place, or (b) register all of FHIR with the AS but
> then decide when a release authorization shows up to override the part that
> has to do with psych notes. Either way, this policy should be obvious to
> the patient at the time of enrollment and AS resource registration.
>
> Adrian
>
>
>
> On Thu, Aug 11, 2016 at 12:15 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Just trying to parse your second must –
>
>
>
> The RS (such as the EMR) MUST expose all patient-level resource to AS
> authorization – even if it decides to override AS authorization in selected
> cases that are disclosed (to whom? – the consumer telling them which AS to
> register, right?) at the time RS-AS resource registration.
>
>
>
> In plain English are you saying that the consumer should be able to tell
> the RS that they have an AS they want to be used and if the RS has policies
> that would over-ride the preferences configured in the AS of the consumer
> the RS needs to tell the consumer that is the case.  So – if I have an AS
> that I have set up to say I am all right sharing my substance abuse related
> data and CFR 42 part 2 applies to the RS – and that facility has decided to
> not allow data that is covered by CFR 42 part 2 – at the time of AS
> registration to the RS you want the RS to tell the consumer that this is
> the case.
>
>
>
> If the consumer has provided an ROI that references this AS somehow and
> tells the RS that they should use that when making disclosure decisions I
> don’t see how the Facility has the authority to ignore the clients wishes
> but I think that is workable.
>
>
>
> The nuance that I am making is that I am saying that the consumer has to
> explicitly say in the ROI that the AS they want used.
>
>
>
> Is that a part of the preconditions we are going down the road with at
> this point?
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Thursday, August 11, 2016 11:53 AM
> *To:* John Moehrke
> *Cc:* Aaron Seib; ddecouteau; Kretz, Jim M. (SAMHSA/CMHS); Gonzales-Webb,
> Suzanne (Engility); Kathleen Connor; Johnathan Coleman [SRS]; Davis, John
> M.; HEART List; Mohammad Jafari
>
>
> *Subject:* Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85,
> Issue 5
>
>
>
> I'm ok with using simple static scopes until UMA figures out how to deal
> with its problem.
>
> However, two things are absolutely required in order to claim that HEART
> is patient-centered:
>
> 1 - The RS MUST accept any UMA-standard AS just like they accept a
> patient's SMTP-standard email domain or telecom carrier.
>
> 2 - The RS MUST expose all patient-level resources to AS authorization
> even if it decides to override AS authorization in selected cases that are
> disclosed at the time of RS-AS resource registration.
>
> Adrian
>
>
>
> On Thu, Aug 11, 2016 at 10:50 AM, John Moehrke <johnmoehrke at gmail.com>
> wrote:
>
> I certainly recognize this as the pattern that OAuth and UMA wants. And I
> encourage us to start here.
>
>
>
> I will caution the overall community that the complexity in healthcare
> data often results in an architecture were the results-about-to-be-returned
> need to be inspected by the Access Control engine so as to filter out items
> that match the query parameters, but which are forbidden from being
> returned because of a Privacy policy.  This is fundimentally why there is
> continuous discussion on the HEART threads. Because those in healthcare
> recognize this fact, and others are advocating for the pattern that can be
> implemented off-the-shelf.
>
>
>
> Recognizing this. I still suggest we go forward using the pattern that is
> available from OAuth and UMA; using simple static scopes.  We can address
> the healthcare complexity later. Otherwise we will continuously circle
> around...
>
>
>
> John
>
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
>
>
> On Thu, Aug 11, 2016 at 9:33 AM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Makes senseto me Professor.
>
>
>
>
>
>
>
> Aaron Seib
>
>
>
> The trick to establishing trust is to avoid all tricks.  Especially tricks
> on yourself.
>
>
>
> -------- Original message --------
> From: Justin Richer <jricher at mit.edu>
> Date: 8/11/16 9:19 AM (GMT-05:00)
> To: Aaron Seib <aaron.seib at nate-trust.org>, Kathleen Connor <
> kathleen_connor at comcast.net>, openid-specs-heart at lists.openid.net
> Cc: ddecouteau <duane.decouteau at gmail.com>, "'Kretz, Jim M.
> (SAMHSA/CMHS)'" <Jim.Kretz at samhsa.hhs.gov>, "'Gonzales-Webb, Suzanne
> (Engility)'" <Suzanne.Gonzales-Webb at va.gov>, jc at securityrs.com, "'Davis,
> John M.'" <Mike.Davis at va.gov>, Mohammad Jafari <mjafari at edmondsci.com>
> Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue
> 5
>
> The point here is that the AS shouldn't ever need to access the payload to
> issue the appropriate tokens. Which it doesn't have to, in either the OAuth
> or UMA models. That's why we say it's always the RS that enforces the
> security of the token (and whatever other additional systems there may be).
> The RS already has the data (obviously, by definition), the AS doesn't.
>
>  -- Justin
>
>
>
> On 8/11/2016 9:02 AM, Aaron Seib wrote:
>
> For what it is worth I have a question regarding Kathleen's assertion that
> accessing the payload would be privacy leaking.
>
>
>
> Would it be the resource owner that accessed the payload in question?
> Don't they already have the content that went into creating the payload?
>
>
>
> Would leakage only be occurring if the AS was seperated from the RS?
>
>
>
>
>
>
>
> Aaron Seib
>
>
>
> The trick to establishing trust is to avoid all tricks.  Especially tricks
> on yourself.
>
>
>
> -------- Original message --------
> From: Kathleen Connor <kathleen_connor at comcast.net>
> <kathleen_connor at comcast.net>
> Date: 8/10/16 11:27 PM (GMT-05:00)
> To: openid-specs-heart at lists.openid.net
> Cc: ddecouteau <duane.decouteau at gmail.com> <duane.decouteau at gmail.com>,
> "'Kretz, Jim M. (SAMHSA/CMHS)'" <Jim.Kretz at samhsa.hhs.gov>
> <Jim.Kretz at samhsa.hhs.gov>, "'Gonzales-Webb, Suzanne (Engility)'"
> <Suzanne.Gonzales-Webb at va.gov> <Suzanne.Gonzales-Webb at va.gov>,
> jc at securityrs.com, "'Davis, John M.'" <Mike.Davis at va.gov>
> <Mike.Davis at va.gov>, Mohammad Jafari <mjafari at edmondsci.com>
> <mjafari at edmondsci.com>
> Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue
> 5
>
> Hi
>
> RE " The scopes are meant to do coarse-grained authorization and not fine
> grained authorization... So, scopes can help you do first level of coarse
> grain authorization which will yield you an access token. Once an access
> token is valid, grab the contextual information from the payload, header,
> access token etc. Find a policy associated with the contextual object, and
> then perform fine level authorization based on the policy."
>
> Different perspective:
>
> Scopes could be conveyed using FHIR Security Labels, which do support fine
> grain authorization, and convey the key policy and context information
> needed without accessing the payload.
>
> Having to access payload to make authorization decisions is privacy
> leaking.
> There's been a lot of work done in this area by VA, ONC, SAMHSA and others
> already. K
>
> Kathleen Connor
> VHA Security Architecture - Framework Engineering
> (Edmond Scientific Company)
> HL7 Security and Financial Management Cochair
> Office - 360 357 3536 [Primary]
> Cell - 360 480 7599
>
> -----Original Message-----
> From: Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] On Behalf Of
> openid-specs-heart-request at lists.openid.net
> Sent: Wednesday, August 10, 2016 11:57 AM
> To: openid-specs-heart at lists.openid.net
> Subject: Openid-specs-heart Digest, Vol 85, Issue 5
>
> Send Openid-specs-heart mailing list submissions to
> openid-specs-heart at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> or, via email, send a message with subject or body 'help' to
> openid-specs-heart-request at lists.openid.net
>
> You can reach the person managing the list at
> openid-specs-heart-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Openid-specs-heart digest..."
>
>
> Today's Topics:
>
>    1. Re: HEART Scope Design Proposal #1 (Vivek Biswas)
>    2. Re: HEART Scope Design Proposal #1
>       (Salyards, Kenneth (SAMHSA/OPPI))
>    3. Re: HEART Scope Design Proposal #1 (Adrian Gropper)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Aug 2016 17:50:18 +0000 (UTC)
> From: Vivek Biswas <vivek_biswas at yahoo.com> <vivek_biswas at yahoo.com>
> To: Adrian Gropper <agropper at healthurl.com> <agropper at healthurl.com>,
> "openid-specs-heart at lists.openid.net"
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> Cc: Josh Mandel <jmandel at gmail.com> <jmandel at gmail.com>, Grahame Grieve
> <grahame at healthintersections.com.au> <grahame at healthintersections.com.au>
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
> Message-ID:
> <1612609796.12186354.1470851418456.JavaMail.yahoo at mail.yahoo.com>
> <1612609796.12186354.1470851418456.JavaMail.yahoo at mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Adrian,
> The scopes are meant to do coarse-grained authorization and not fine
> grained
> authorization.
>
> And hence, this one of the reason why scopes are static string.
> If one want to perform fine grained authorization, then its based on lot of
> contextual information like you mention, date-range, geo-location, etc....
> The contextual information can reside in the Request Payload, in database,
> within the access token (if JWT) etc. All these contextual information
> associated with the request can be trusted only if the access token is
> valid.?
> There can be a policy associated with context which can help us to decide
> if
> the request should be authorized or not.
> So, scopes can help you do first level of coarse grain authorization which
> will yield you an access token. Once an access token is valid, grab the
> contextual information from the payload, header, access token etc. Find a
> policy associated with the contextual object and than perform fine level
> authorization based on the policy.
>
> RegardsVivek Biswas, CISSPConsulting Member @Oracle
>
>
>       From: Adrian Gropper <agropper at healthurl.com>
> <agropper at healthurl.com>
> To: "openid-specs-heart at lists.openid.net"
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> Cc: Justin Richer <jricher at mit.edu> <jricher at mit.edu>; Vivek Biswas
> <vivek_biswas at yahoo.com> <vivek_biswas at yahoo.com>;
> Josh Mandel <jmandel at gmail.com> <jmandel at gmail.com>; Grahame Grieve
> <grahame at healthintersections.com.au> <grahame at healthintersections.com.au>
> Sent: Tuesday, August 9, 2016 12:57 PM
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
>
> There are many reasons why we need to find a way:
>
>    - I have never seen a release of information form that did not have a
> date range. Has anyone? If we say HEART can't do that we're calling into
> question the legitimacy of HEART.
>    - We have a lot of experience with 75-page CCDAs with the current
> standards. Many patients have huge health records and it is
> resource-intensive to get 74-pages of information you already had in order
> to find the change from the last encounter. The cost is not just on the
> sender but on the recipient as well. This is probably the top complaint of
> the current interop methods in my medical society.
>    - I don't think the HEART charter set a particular limit on how much of
> FHIR we would manage. It's not in our charter to treat effective
> provider-to-provider exchange as out-of-scope. Once we say that HEART will
> not support the full patient-level feature set of FHIR, where do we draw
> the
> line?
>    - UMA is not OAuth. The goals of the two standards are very different.
> UMA and HEART are patient-centered. If we restrict HEART to a small
> fraction
> of the longitudinal health records or patient-centered health rerecords
> transactions (because most of the traffic stays in the batch or
> institution-to-institution domain) then where do we host the discussion on
> a
> future for patient-centered records?
>    - There is no logical reason for HEART to not support date ranges once
> FHIR has that capability. In some jurisdictions, this would be seen as
> reducing patient's right of access and subject to legal challenge.
>
> I've added Josh and Grahame to this thread. Let's try and find the solution
> to this problem even if it involves changing UMA, FHIR or both.
> Adrian
>
> On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <vivek_biswas at yahoo.com>
> <vivek_biswas at yahoo.com>
> wrote:
>
> I agree with Justin, that scopes are static string vs scope string be
> parameterized. Most of the OAuth server support static string.?
> It will get challenging to implement a profile which requires dynamic
> string
> which in turn will hamper the adoption of HEART.
> We are trying to add contextual information into the scope which are not
> what scopes are intended for.
> RegardsVivek Biswas, CISSPConsulting member @Oracle?
> On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher at mit.edu>
> <jricher at mit.edu> wrote:
>
>
> A problem I can see with this is that the ?date? field in particular moves
> this from something that?s expressible as a table of known strings (like in
> the appendix of the current spec) to something that?s dynamically
> parameterized with a potentially infinite set of values. This is a problem
> in practice as many OAuth implementations treat all scopes as static
> strings, and will do things like limit set set of scopes a client is
> allowed
> to ask for based on a set of registered strings. That?s not possible with a
> field like ?date? anymore, since the value is filled in at runtime. We
> tried
> to have parameterized scopes in BB+ (and even implemented it) but it was
> generally thought to be too complicated, and required special tooling at
> the
> authorizations server.
> If at all possible, I?d like HEART scopes to not require such special
> processing and support at the AS.
>
> ?? Justin
>
> On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper at healthurl.com>
> <agropper at healthurl.com> wrote:
> Scope Design Proposal #1 aims to support a typical ROI authorization.
>
> The structure of SDP1 is: patient/date/confidentialitycl ass/resource/edit
>
> The logic is as follows:
>
>    - /patient because this applies to only one patient at a time. The
> patient ID is local to the resource server.
>    - /date is defined by FHIR and can be a range. Putting it at the highest
> level in the hierarchy (if a scope hierarchy is useful) allows for
> efficiency in clients requesting updates and reduces the cost to the
> resource server
>    - /confidentialityclass filters for resources at or below the specified
> value. Resources that do not have a confidentiality class are considered N
> -
> Normal. It is up to the resource server to provide jurisdictictionally
> appropriate policies and user interfaces for setting confidentiality class
> other than N on particular resources.
>    - /resource is any resource listed in the particular version of the FHIR
> specification
>    - /edit is "read", "write", "any" operation by the client on the
> resource
> A client might request a scope for immunizations for patient 23 as:[
> "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]
>
> on a resource registered as: [base]/Patient/23/ with a reference to HEART
> scopes SDP1 that would tell both the AS and anyone else that dereferenced
> HEART/SDP1 that the RS would process specific scope strings for date,
> confidentialityclass, resource, and edit as described above.
>
> The AS would be free to present SDP1 to the RO any way that it chose.
>
> A resource server like NYP that wanted to offer registration for sensitive
> data like Mental Health Treatment would register another resource:
> [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.
> These additional resources would not be specified by HEART.
>
> Any particular RS could choose to support Confidentiality Class, additional
> resources, neither, or both.
>
> It would be up to the AS to combine HEART SDP1 resources and additional
> resources and scopes offered by the RS into whatever policy setting
> experience it wanted.
> With this scheme, an AS might offer Alice a policy setting for Observation
> =
> R - Restricted even on a resource server that did not support
> confidentiality class. This would cause all client requests for
> Observations
> to fail because the RS would be forced to treat unlabeled resources as N
> and
> the authorization tokens for observations were R. The RS could:
> (a) ignore this problem and treat it as an AS bug,
> (b) implement confidentiality classification, or
> (c) offer additional resources and scopes so that the AS could tell Alice
> that Observations did not include those related to mental health in the
> hope
> that Alice would set Observation = N and deal with mental health as a
> separate part of her policy.
>
> I believe that, to a first approximation, SDP1 would capture the
> functionality of most sharing use-cases without forcing the RS to do
> anything more than it is jurisdictionally already required to do.
> Adrian
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE:http://patientprivacyrights.
> org/donate-2/______________________________ _________________
> Openid-specs-heart mailing list 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
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE:http://patientprivacyrights.org/donate-2/
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160810/2
> d199baa/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Aug 2016 18:49:42 +0000
> From: "Salyards, Kenneth (SAMHSA/OPPI)"
> <Kenneth.Salyards at SAMHSA.hhs.gov> <Kenneth.Salyards at SAMHSA.hhs.gov>
> To: Vivek Biswas <vivek_biswas at yahoo.com> <vivek_biswas at yahoo.com>,
> Adrian Gropper
> <agropper at healthurl.com> <agropper at healthurl.com>,
> "openid-specs-heart at lists.openid.net"
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> Cc: Josh Mandel <jmandel at gmail.com> <jmandel at gmail.com>, Grahame Grieve
> <grahame at healthintersections.com.au> <grahame at healthintersections.com.au>
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
> Message-ID:
>
> <CY1PR09MB09394BE450F53C13200ECF8CA81D0 at CY1PR09MB0939.
> namprd09.prod.outlook.
> com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Fine grained authorization should be dealt with using a patients? consent
> directive. FHIR DSTU2 supports consent directive as part of the contract
> resource. In DSTU3, as I understand the consent directive will not be part
> of contract. This can work seamlessly within the UMA resource server
> construct. Ken
>
> From: Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Vivek
> Biswas
> Sent: Wednesday, August 10, 2016 1:50 PM
> To: Adrian Gropper; openid-specs-heart at lists.openid.net
> Cc: Josh Mandel; Grahame Grieve
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
>
> Hi Adrian,
>
> The scopes are meant to do coarse-grained authorization and not fine
> grained
> authorization.
>
> And hence, this one of the reason why scopes are static string.
>
> If one want to perform fine grained authorization, then its based on lot of
> contextual information like you mention, date-range, geo-location, etc....
>
> The contextual information can reside in the Request Payload, in database,
> within the access token (if JWT) etc. All these contextual information
> associated with the request can be trusted only if the access token is
> valid.
>
> There can be a policy associated with context which can help us to decide
> if
> the request should be authorized or not.
>
> So, scopes can help you do first level of coarse grain authorization which
> will yield you an access token. Once an access token is valid, grab the
> contextual information from the payload, header, access token etc. Find a
> policy associated with the contextual object and than perform fine level
> authorization based on the policy.
>
>
> Regards
> Vivek Biswas, CISSP
> Consulting Member @Oracle
>
>
>
> ________________________________
> From: Adrian Gropper <agropper at healthurl.com<
> mailto:agropper at healthurl.com> <agropper at healthurl.com>>
> To:
> "openid-specs-heart at lists.openid.net<mailto:openid-
> specs-heart at lists.openid <openid-specs-heart at lists.openid>.
> net>"
> <openid-specs-heart at lists.openid.net<mailto:openid-
> specs-heart at lists.openid <openid-specs-heart at lists.openid>.
> net>>
> Cc: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>
> <jricher at mit.edu>>; Vivek Biswas
> <vivek_biswas at yahoo.com<mailto:vivek_biswas at yahoo.com>
> <vivek_biswas at yahoo.com>>; Josh Mandel
> <jmandel at gmail.com<mailto:jmandel at gmail.com> <jmandel at gmail.com>>;
> Grahame Grieve
> <grahame at healthintersections.com.au<mailto:grahame@
> healthintersections.com.a <grahame at healthintersections.com.a>
> u>>
> Sent: Tuesday, August 9, 2016 12:57 PM
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
>
> There are many reasons why we need to find a way:
>
>   1.  I have never seen a release of information form that did not have a
> date range. Has anyone? If we say HEART can't do that we're calling into
> question the legitimacy of HEART.
>   2.  We have a lot of experience with 75-page CCDAs with the current
> standards. Many patients have huge health records and it is
> resource-intensive to get 74-pages of information you already had in order
> to find the change from the last encounter. The cost is not just on the
> sender but on the recipient as well. This is probably the top complaint of
> the current interop methods in my medical society.
>   3.  I don't think the HEART charter set a particular limit on how much of
> FHIR we would manage. It's not in our charter to treat effective
> provider-to-provider exchange as out-of-scope. Once we say that HEART will
> not support the full patient-level feature set of FHIR, where do we draw
> the
> line?
>   4.  UMA is not OAuth. The goals of the two standards are very different.
> UMA and HEART are patient-centered. If we restrict HEART to a small
> fraction
> of the longitudinal health records or patient-centered health rerecords
> transactions (because most of the traffic stays in the batch or
> institution-to-institution domain) then where do we host the discussion on
> a
> future for patient-centered records?
>   5.  There is no logical reason for HEART to not support date ranges once
> FHIR has that capability. In some jurisdictions, this would be seen as
> reducing patient's right of access and subject to legal challenge.
> I've added Josh and Grahame to this thread. Let's try and find the solution
> to this problem even if it involves changing UMA, FHIR or both.
> Adrian
>
> On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas
> <vivek_biswas at yahoo.com<mailto:vivek_biswas at yahoo.com>
> <vivek_biswas at yahoo.com>> wrote:
> I agree with Justin, that scopes are static string vs scope string be
> parameterized. Most of the OAuth server support static string.
>
> It will get challenging to implement a profile which requires dynamic
> string
> which in turn will hamper the adoption of HEART.
>
> We are trying to add contextual information into the scope which are not
> what scopes are intended for.
>
> Regards
> Vivek Biswas, CISSP
> Consulting member @Oracle
>
> On Aug 9, 2016, at 9:17 AM, Justin Richer
> <jricher at mit.edu<mailto:jricher at mit.edu> <jricher at mit.edu>> wrote:
> A problem I can see with this is that the ?date? field in particular moves
> this from something that?s expressible as a table of known strings (like in
> the appendix of the current spec) to something that?s dynamically
> parameterized with a potentially infinite set of values. This is a problem
> in practice as many OAuth implementations treat all scopes as static
> strings, and will do things like limit set set of scopes a client is
> allowed
> to ask for based on a set of registered strings. That?s not possible with a
> field like ?date? anymore, since the value is filled in at runtime. We
> tried
> to have parameterized scopes in BB+ (and even implemented it) but it was
> generally thought to be too complicated, and required special tooling at
> the
> authorizations server.
>
> If at all possible, I?d like HEART scopes to not require such special
> processing and support at the AS.
>
> ? Justin
>
> On Aug 8, 2016, at 9:08 PM, Adrian Gropper
> <agropper at healthurl.com<mailto:agropper at healthurl.com>
> <agropper at healthurl.com>> wrote:
>
> Scope Design Proposal #1 aims to support a typical ROI
> authorization<https://dl.dropboxusercontent.com/u/
> 8909568/NYP%20authorizatio
> n.pdf>.
> The structure of SDP1 is:
> patient/date<http://hl7.org/fhir/search.html#date>
> <http://hl7.org/fhir/search.html#date>/confidentialitycl
> ass<http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>
> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/reso
> urce<http://hl7.org/fhir/resourcelist.html>
> <http://hl7.org/fhir/resourcelist.html>/edit
>
> The logic is as follows:
>
>   *   /patient because this applies to only one patient at a time. The
> patient ID is local to the resource server.
>   *   /date<http://hl7.org/fhir/search.html#date>
> <http://hl7.org/fhir/search.html#date> is defined by FHIR and can
> be a range. Putting it at the highest level in the hierarchy (if a scope
> hierarchy is useful) allows for efficiency in clients requesting updates
> and
> reduces the cost to the resource server
>   *
> /confidentialityclass<http://hl7-fhir.github.io/v3/
> ConfidentialityClassifica
> tion/vs.html> filters for resources at or below the specified value.
> Resources that do not have a confidentiality class are considered N -
> Normal. It is up to the resource server to provide jurisdictictionally
> appropriate policies and user interfaces for setting confidentiality class
> other than N on particular resources.
>   *   /resource<http://hl7.org/fhir/resourcelist.html>
> <http://hl7.org/fhir/resourcelist.html> is any resource
> listed in the particular version of the FHIR specification
>   *   /edit is "read", "write", "any" operation by the client on the
> resource
> A client might request a scope for immunizations for patient 23 as:
>
> [ "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]
>
> on a resource registered as: [base]/Patient/23/ with a reference to HEART
> scopes SDP1 that would tell both the AS and anyone else that dereferenced
> HEART/SDP1 that the RS would process specific scope strings for date,
> confidentialityclass, resource, and edit as described above.
>
> The AS would be free to present SDP1 to the RO any way that it chose.
>
> A resource server like NYP that wanted to offer registration for sensitive
> data like Mental Health Treatment would register another resource:
> [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.
> These additional resources would not be specified by HEART.
>
> Any particular RS could choose to support Confidentiality Class, additional
> resources, neither, or both.
>
> It would be up to the AS to combine HEART SDP1 resources and additional
> resources and scopes offered by the RS into whatever policy setting
> experience it wanted.
> With this scheme, an AS might offer Alice a policy setting for Observation
> =
> R - Restricted even on a resource server that did not support
> confidentiality class. This would cause all client requests for
> Observations
> to fail because the RS would be forced to treat unlabeled resources as N
> and
> the authorization tokens for observations were R. The RS could:
> (a) ignore this problem and treat it as an AS bug,
> (b) implement confidentiality classification, or
> (c) offer additional resources and scopes so that the AS could tell Alice
> that Observations did not include those related to mental health in the
> hope
> that Alice would set Observation = N and deal with mental health as a
> separate part of her policy.
> I believe that, to a first approximation, SDP1 would capture the
> functionality of most sharing use-cases without forcing the RS to do
> anything more than it is jurisdictionally already required to do.
>
> Adrian
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.
> org/donate-2/<http://patientprivacyrights.org/donate-2/>
> <http://patientprivacyrights.org/donate-2/>
> ______________________________ _________________ Openid-specs-heart mailing
> list Openid-specs-heart at lists.
> openid.net<mailto:Openid-specs-heart at lists.openid.net>
> <Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/ mailman/listinfo/openid-specs-
> heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
> ______________________________ _________________ Openid-specs-heart mailing
> list Openid-specs-heart at lists.
> openid.net<mailto:Openid-specs-heart at lists.openid.net>
> <Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/ mailman/listinfo/openid-specs-
> heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160810/3
> 8084e5a/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Aug 2016 14:57:02 -0400
> From: Adrian Gropper <agropper at healthurl.com> <agropper at healthurl.com>
> To: "Salyards, Kenneth (SAMHSA/OPPI)"
> <Kenneth.Salyards at samhsa.hhs.gov> <Kenneth.Salyards at samhsa.hhs.gov>
> Cc: Grahame Grieve <grahame at healthintersections.com.au>
> <grahame at healthintersections.com.au>, Josh Mandel
> <jmandel at gmail.com> <jmandel at gmail.com>, "openid-specs-heart at lists.
> openid.net" <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1
> Message-ID:
> <CANYRo8goY-qq=iM+KFNP2=YKNzp9c_RH8Ld5ceLLs=iFbabRig at mail.gmail.com>
> <CANYRo8goY-qq=iM+KFNP2=YKNzp9c_RH8Ld5ceLLs=iFbabRig at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> What is a consent directive?
>
> What is the relationship of whatever it is to FHIR or any other standard
> data model?
>
> How does a consent directive interact with OAuth, UMA or OpenID Connect?
>
> Do you have an example of how a consent directive maps into, replaces, or
> changes the NYP ROI authorization form?
>
> Thanks,
>
> Adrian
>
>
>
> On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI) <
> Kenneth.Salyards at samhsa.hhs.gov> wrote:
>
> > Fine grained authorization should be dealt with using a patients?
> > consent directive. FHIR DSTU2 supports consent directive as part of
> > the contract resource. In DSTU3, as I understand the consent directive
> > will not be part of contract. This can work seamlessly within the UMA
> > resource server construct. Ken
> >
> >
> >
> > *From:* Openid-specs-heart [mailto:openid-specs-heart
> <openid-specs-heart>-
> > bounces at lists.openid.net] *On Behalf Of *Vivek Biswas
> > *Sent:* Wednesday, August 10, 2016 1:50 PM
> > *To:* Adrian Gropper; openid-specs-heart at lists.openid.net
> > *Cc:* Josh Mandel; Grahame Grieve
> >
> > *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1
> >
> >
> >
> > Hi Adrian,
> >
> >
> >
> > The scopes are meant to do coarse-grained authorization and not fine
> > grained authorization.
> >
> >
> >
> > And hence, this one of the reason why scopes are static string.
> >
> >
> >
> > If one want to perform fine grained authorization, then its based on
> > lot of contextual information like you mention, date-range,
> > geo-location, etc....
> >
> >
> >
> > The contextual information can reside in the Request Payload, in
> > database, within the access token (if JWT) etc. All these contextual
> > information associated with the request can be trusted only if the
> > access token is valid.
> >
> >
> >
> > There can be a policy associated with context which can help us to
> > decide if the request should be authorized or not.
> >
> >
> >
> > So, scopes can help you do first level of coarse grain authorization
> > which will yield you an access token. Once an access token is valid,
> > grab the contextual information from the payload, header, access token
> > etc. Find a policy associated with the contextual object and than
> > perform fine level authorization based on the policy.
> >
> >
> >
> >
> >
> > Regards
> >
> > Vivek Biswas, CISSP
> >
> > Consulting Member @Oracle
> >
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > *From:* Adrian Gropper <agropper at healthurl.com> <agropper at healthurl.com>
> > *To:* "openid-specs-heart at lists.openid.net"
> <openid-specs-heart at lists.openid.net> <openid-specs-heart at lists.
> <openid-specs-heart at lists.%0b>> openid.net>
> > *Cc:* Justin Richer <jricher at mit.edu> <jricher at mit.edu>; Vivek Biswas <
> > vivek_biswas at yahoo.com>; Josh Mandel <jmandel at gmail.com>
> <jmandel at gmail.com>; Grahame
> > Grieve < grahame at healthintersections.com.au>
> > *Sent:* Tuesday, August 9, 2016 12:57 PM
> > *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1
> >
> >
> >
> > There are many reasons why we need to find a way:
> >
> >    1. I have never seen a release of information form that did not have a
> >    date range. Has anyone? If we say HEART can't do that we're calling
> into
> >    question the legitimacy of HEART.
> >    2. We have a lot of experience with 75-page CCDAs with the current
> >    standards. Many patients have huge health records and it is
> >    resource-intensive to get 74-pages of information you already had in
> order
> >    to find the change from the last encounter. The cost is not just on
> the
> >    sender but on the recipient as well. This is probably the top
> complaint
> of
> >    the current interop methods in my medical society.
> >    3. I don't think the HEART charter set a particular limit on how much
> >    of FHIR we would manage. It's not in our charter to treat effective
> >    provider-to-provider exchange as out-of-scope. Once we say that HEART
> will
> >    not support the full patient-level feature set of FHIR, where do we
> draw
> >    the line?
> >    4. UMA is not OAuth. The goals of the two standards are very
> >    different. UMA and HEART are patient-centered. If we restrict HEART to
> a
> >    small fraction of the longitudinal health records or patient-centered
> >    health rerecords transactions (because most of the traffic stays in
> the
> >    batch or institution-to-institution domain) then where do we host the
> >    discussion on a future for patient-centered records?
> >    5. There is no logical reason for HEART to not support date ranges
> >    once FHIR has that capability. In some jurisdictions, this would be
> seen as
> >    reducing patient's right of access and subject to legal challenge.
> >
> > I've added Josh and Grahame to this thread. Let's try and find the
> > solution to this problem even if it involves changing UMA, FHIR or both.
> >
> > Adrian
> >
> >
> >
> > On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <vivek_biswas at yahoo.com>
> <vivek_biswas at yahoo.com>
> > wrote:
> >
> > I agree with Justin, that scopes are static string vs scope string be
> > parameterized. Most of the OAuth server support static string.
> >
> >
> >
> > It will get challenging to implement a profile which requires dynamic
> > string which in turn will hamper the adoption of HEART.
> >
> >
> >
> > We are trying to add contextual information into the scope which are
> > not what scopes are intended for.
> >
> >
> > Regards
> >
> > Vivek Biswas, CISSP
> >
> > Consulting member @Oracle
> >
> >
> > On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher at mit.edu>
> <jricher at mit.edu> wrote:
> >
> > A problem I can see with this is that the ?date? field in particular
> > moves this from something that?s expressible as a table of known
> > strings (like in the appendix of the current spec) to something that?s
> > dynamically parameterized with a potentially infinite set of values.
> > This is a problem in practice as many OAuth implementations treat all
> > scopes as static strings, and will do things like limit set set of
> > scopes a client is allowed to ask for based on a set of registered
> > strings. That?s not possible with a field like ?date? anymore, since
> > the value is filled in at runtime. We tried to have parameterized
> > scopes in BB+ (and even implemented
> > it) but it was generally thought to be too complicated, and required
> > special tooling at the authorizations server.
> >
> >
> >
> > If at all possible, I?d like HEART scopes to not require such special
> > processing and support at the AS.
> >
> >
> >
> >  ? Justin
> >
> >
> >
> > On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper at healthurl.com>
> <agropper at healthurl.com> wrote:
> >
> >
> >
> > Scope Design Proposal #1 aims to support a typical ROI authorization
> > <https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf>
> <https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf>.
> >
> > The structure of SDP1 is: patient/date
> > <http://hl7.org/fhir/search.html#date>
> <http://hl7.org/fhir/search.html#date>/confidentialitycl ass
> > <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>
> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/
> > resource <http://hl7.org/fhir/resourcelist.html>
> <http://hl7.org/fhir/resourcelist.html>/edit
> >
> >
> > The logic is as follows:
> >
> >    - /patient because this applies to only one patient at a time. The
> >    patient ID is local to the resource server.
> >    - /date <http://hl7.org/fhir/search.html#date>
> <http://hl7.org/fhir/search.html#date> is defined by FHIR and
> >    can be a range. Putting it at the highest level in the hierarchy (if a
> >    scope hierarchy is useful) allows for efficiency in clients requesting
> >    updates and reduces the cost to the resource server
> >    - /confidentialityclass
> >    <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>
> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>
> >    filters for resources at or below the specified value. Resources that
> do
> >    not have a confidentiality class are considered N - Normal. It is up
> to
> the
> >    resource server to provide jurisdictictionally appropriate policies
> and
> >    user interfaces for setting confidentiality class other than N on
> >    particular resources.
> >    - /resource <http://hl7.org/fhir/resourcelist.html>
> <http://hl7.org/fhir/resourcelist.html> is any resource
> >    listed in the particular version of the FHIR specification
> >    - /edit is "read", "write", "any" operation by the client on the
> >    resource
> >
> > A client might request a scope for immunizations for patient 23 as:
> >
> > [ "date=le2016-8-8","conclass=N" , "resource=Immunization",
> > "edit=read" ]
> >
> > on a resource registered as: [base]/Patient/23/ with a reference to
> > HEART scopes SDP1 that would tell both the AS and anyone else that
> > dereferenced HEART/SDP1 that the RS would process specific scope strings
> for date, confidentialityclass, resource, and edit as described above.
> >
> > The AS would be free to present SDP1 to the RO any way that it chose.
> >
> > A resource server like NYP that wanted to offer registration for
> > sensitive data like Mental Health Treatment would register another
> resource: [base]/Patient/23/ MentalHealthTx with whatever scopes it
> offered.
> > These additional resources would not be specified by HEART.
> >
> > Any particular RS could choose to support Confidentiality Class,
> additional resources, neither, or both.
> >
> > It would be up to the AS to combine HEART SDP1 resources and additional
> resources and scopes offered by the RS into whatever policy setting
> experience it wanted.
> >
> > With this scheme, an AS might offer Alice a policy setting for
> > Observation = R - Restricted even on a resource server that did not
> > support confidentiality class. This would cause all client requests
> > for Observations to fail because the RS would be forced to treat
> > unlabeled resources as N and the authorization tokens for observations
> > were R. The RS
> > could:
> > (a) ignore this problem and treat it as an AS bug,
> > (b) implement confidentiality classification, or
> > (c) offer additional resources and scopes so that the AS could tell
> > Alice that Observations did not include those related to mental health
> > in the hope that Alice would set Observation = N and deal with mental
> > health as a separate part of her policy.
> >
> > I believe that, to a first approximation, SDP1 would capture the
> > functionality of most sharing use-cases without forcing the RS to do
> > anything more than it is jurisdictionally already required to do.
> >
> > Adrian
> >
> >
> >
> >
> > --
> >
> >
> >
> > Adrian Gropper MD
> >
> > PROTECT YOUR FUTURE - RESTORE Health Privacy!
> > HELP us fight for the right to control personal health data.
> > DONATE: http://patientprivacyrights. org/donate-2/
> > <http://patientprivacyrights.org/donate-2/>
> <http://patientprivacyrights.org/donate-2/>
> >
> > ______________________________ _________________ Openid-specs-heart
> > mailing list Openid-specs-heart at lists. openid.net
> > <Openid-specs-heart at lists.openid.net>
> <Openid-specs-heart at lists.openid.net>
> > http://lists.openid.net/ mailman/listinfo/openid-specs- heart
> > <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> >
> >
> >
> > ______________________________ _________________ Openid-specs-heart
> > mailing list Openid-specs-heart at lists. openid.net
> > <Openid-specs-heart at lists.openid.net>
> <Openid-specs-heart at lists.openid.net>
> > http://lists.openid.net/ mailman/listinfo/openid-specs- heart
> > <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> >
> >
> >
> >
> > --
> >
> >
> >
> > Adrian Gropper MD
> >
> > PROTECT YOUR FUTURE - RESTORE Health Privacy!
> > HELP us fight for the right to control personal health data.
> > DONATE: http://patientprivacyrights.org/donate-2/
> >
> >
> >
>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openid.net/pipermail/openid-specs-heart/
> attachments/20160810/1
> d44ada3/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> ------------------------------
>
> End of Openid-specs-heart Digest, Vol 85, Issue 5
> *************************************************
>
> _______________________________________________
> Openid-specs-heart mailing list
> 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
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> 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
>
>
>
>
> --
>
>
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>
>
> --
>
>
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160811/6a7b8278/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3205 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160811/6a7b8278/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160811/6a7b8278/attachment-0003.jpg>

More information about the Openid-specs-heart mailing list