[Openid-specs-heart] Federal / HHS API interop working group

Aaron Seib aaron.seib at nate-trust.org
Mon Dec 28 23:49:57 UTC 2015


Ish

 

I am one of the 11 members as well  so I can certainly share what I know but I am still hoping that you are encouraged to provide your insight and expertise to the Task Force as well.  The more informed voices that contribute the better.

 

One of the articles listed out the objectives for the group as (glossing over the focus on real risks included here in red):

·        Identify perceived security concerns and real risks that prohibit API adoption, 

*	For risks identified as real, identify those that are not already planned to be addressed in the Interoperability Roadmap (for example, identity proofing and authentication are not unique to APIs);

·        Identify perceived privacy concerns and real risks that prohibit API adoption, and

*	For risks identified as real, identify those that are not already planned to be addressed in the Interoperability Roadmap (for example, harmonizing state law and misunderstanding of HIPAA);

·        Identify priority recommendations for ONC that will help enable consumers to leverage API technology to access patient data, while ensuring the appropriate level of privacy and security protection."

 

I would welcome your inputs - along with anyone else’s - on what are the real privacy and security risks that will slow down adoption and the prioritized recommendations on how to address them.

 

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843



 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Moehrke, John (GE Healthcare)
Sent: Monday, December 28, 2015 5:34 PM
To: Ishmal Bartley; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Federal / HHS API interop working group

 

Hi Ishmal,

 

The task force is co-chaired by Josh Mandel, who does participate in HEART when he can and was one of the minds behind SMART, and is a FHIR Core Team… So this task force is in good hands.

 

There might be others. Here is the membership

 


Josh Mandel

Harvard Medical School


Meg Marshall

Cerner


Leslie Kelly Hall

Healthwise


Robert Jarrin

Qualcomm Incorporated


Rajiv Kumar

Stanford University School of Medicine


Richard Loomis

Practice Fusion


Aaron Miri

Walnut Hill Medical Center


Drew Schiller

Validic


Aaron Seib

National Association for Trusted Exchange


David Yakimischak 

Surescripts


Ivor Horn

Seattle Children's

 

 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Ishmal Bartley
Sent: Monday, December 28, 2015 12:53 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Federal / HHS API interop working group

 

Hello All,

The articles below describe Health Data API work underway. Specifically they are looking to address privacy and operability concerns from the consumer perspective.

I sincerely hope that someone familiar with Heart, UMA Core, OAuth and the UC"s that this group has been working through is involved with this work. If not it may be worthwhile to beat the bushes and figure out how to get invited to the meetings. 

If HHS is sponsoring this work this could be beginning of the "one ring to rule them all"...

 

 

http://www.programmableweb.com/news/healthcare-api-task-force-launched/elsewhere-web/2015/12/24?utm_campaign=15-12-28-TIA+%28idFrze%29 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.programmableweb.com_news_healthcare-2Dapi-2Dtask-2Dforce-2Dlaunched_elsewhere-2Dweb_2015_12_24-3Futm-5Fcampaign-3D15-2D12-2D28-2DTIA-2B-2528idFrze-2529-26utm-5Fmedium-3Demail-26-5Fke-3DaWJhcnRsZXkyMDA3QGdtYWlsLmNvbQ-253D-253D-26utm-5Fsource-3DPWT&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=I9qJokOV5qj3dPWqfIjPCieSAvh4kfRAiX1oddWBfic&e=> &utm_medium=email&_ke=aWJhcnRsZXkyMDA3QGdtYWlsLmNvbQ%3D%3D&utm_source=PWT

 

 

http://www.fiercegovernmentit.com/story/healthcare-api-task-force-gets-work/2015-12-07 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fiercegovernmentit.com_story_healthcare-2Dapi-2Dtask-2Dforce-2Dgets-2Dwork_2015-2D12-2D07&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=JO-6OSxn3is4mYhpLJ5il43KefbJtg4HR3pjAltxGUU&e=> 

 

 

Merry Christmas To All!

 

Ishmal Bartley

-TarIS

 

On Mon, Dec 21, 2015 at 2:59 PM, <openid-specs-heart-request at lists.openid.net> wrote:

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=EBTeu4GenY3ZNO2bT1MReiyrcyRL9X3ktfT3byPwWr0&e=> 
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. HEART Agenda 2015-12-21 (Debbie Bucci)
   2. Draft HEART Meeting Notes 2015-12-21 (Sarah Squire)
   3. Re: Draft HEART Meeting Notes 2015-12-21 (Aaron Seib)


----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Dec 2015 09:01:45 -0500
From: Debbie Bucci <debbucci at gmail.com>
To: "openid-specs-heart at lists.openid.net"
        <openid-specs-heart at lists.openid.net>
Subject: [Openid-specs-heart] HEART Agenda 2015-12-21
Message-ID:
        <CAG6zQ1YF6Rg7FQotCvNU0vpw7=JWsfoBusXkn0a8tiNc_7zyCw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

*When: 1 PM PST/4 PM EST*

*Where: Gotomeeting ? *https://global.gotomeeting.com/join/785234357

*US phone number*: +1 (619) 550-0003 <tel:%2B1%20%28619%29%20550-0003> . Access Code 785-234-357




*Agenda :*

   - Follow up on recent threads
   - AOB

Sorry for an even later agenda.   Distracted with holiday
activities/preparations.   Have no planned agenda but figured we should
meet - even if for a portion of the time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/bb4a61cd/attachment-0001.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_bb4a61cd_attachment-2D0001.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=a0r7w5Bpx-pSpNHEdPyNZ12h_n3I_O1q5qTMdZjLGXA&e=> >

------------------------------

Message: 2
Date: Mon, 21 Dec 2015 14:00:11 -0800
From: Sarah Squire <sarah at engageidentity.com>
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
Message-ID:
        <CAN1PkMYOSOHosK0=_AHDfi1mG9dy9kWXY0gat5oeB1BC4C41uA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Attendees:

Debbie Bucci

Sarah Squire

Justin Richer

Eve Maler

Glen Marshall

Aaron Seib

Kenneth Salyards

Brandon Smith

Adrian Gropper

Thomas Sullivan

Dale Moberg

Group consensus decision: we will restrict HEART to use cases where one
resource is only protected by one authorization server

Glen:

I?ll be working on my use case for quick discussion in January.

Debbie:

Should we talk about one or more authorization servers?

Aaron:

It seems like sometimes HEART gets bogged down in things that would be
better served by a policy group.

Glen:

I was trying to find the boundaries between specs and policy.

Aaron:

The API task force is dependent on the HEART group

Glen:

We need to consider the practical operations to move toward a better
standardized technology

Aaron:

is there a difference between our approach to an individual as opposed to
more than one person? We just need to serialize it.

Justin:

What do you mean by serialize it? The fact that it is being transmitted
means that it?s by definition serialization.

Aaron:

I just meant we should go through the list one thing as a time.

Eve:

Are you talking about separating the data so that it?s about one person?

Aaron:

That?s the way I understand a person would do it.

Eve:

We could take the approach that if we?re patient-centric, then back channel
transfer of data about multiple-people. Should multiple people be out of
scope?

Debbie:

Except when the multiple people are ?my family.?

Justin:

It?s in scope in our existing use cases.

Adrian:

Once we allow for multiple patients in a resource, a lot of people who are
not as sophisticated are going to bundle discovery. The caregiver has
nothing to do with discovery. As soon as you get to the user having
role-based access, then there?s a discovery process.

Sarah:

Why wouldn?t you know what?s on the list?

Adrian:

If there?s a list, you need discovery

Justin:

There?s no discovery

Adrian:

>From the client?s perspective, how does it know which authorization server
to talk to?

Sarah:

There?s only one authorization server involved in this transaction

Aaron:

How do we comply with laws saying that medical records of wives should not
be disclosed to abusive husbands?

Sarah:

By virtue of this system being patient-centered, the patient can control
access to her data.

Justin:

The resource server can deny an access token for any reason, so you could
do it that way.

Glen:

If we had a case where there were multiple ASs, it would be possible to
have a resource server prepared to interpret all of those rules, some of
which may be mutually exclusive. There is no grammar for the combinatoric
aspects of multiple ASs.

Justin:

There is a project working on that called XACML. It doesn?t work at all.

Glen:

XACML doesn?t handle policies coming out of left field like the domestic
violence policy.

Adrian:

Why not work with the UMA we have now rather than involving this
complicated problem?

Glen:

I agree. What I was trying to get to is that there is a class of use cases
that we shouldn?t be dealing with.

Justin:

I agree there?s a class of use cases that we don?t have the right tools
for.

Glen:

In clinical research, we often grab bulk data, so solving for that is
helpful.

Adrian:

Is there something about UMA 1.0.1 that works for the single authorization
server use case

Eve:

I cannot figure out from this conversation what the multiple records use
case is a problem.

Justin:

If a bulk request includes resources with multiple authorization servers,
we don?t know which AS to talk to. If we define the bulk access record so
that there?s only one AS, it works fine. Or if there?s an implicit AS it?s
fine. Throughout all of this, we need to be very clear on the nature of the
API that?s being protected when we?re designing security profiles.

Eve:

If data is restricted but then aggregated, is that still UMA?

Justin:

That?s out of scope. That?s a cache consistency problem.

Eve:

But we can do it with chained delegation.

Debbie:

Do they have to be in the same domain?

Eve:

They just have to be in the same ecosystem

Eve:

We?re talking about data portability of metadata. A resource set identifier
is metadata that?s sensitive information that an AS knows about a user.
You?d have to share it with another AS to be portable across networks. So
we?re talking about something that I?ve worked on. It?s good that we?re
talking about it. It?s not trivial for privacy or portability.

Sarah:

It sounds like it?s not fully baked enough to be within scope for HEART,
correct?

Eve:

Correct.

Adrian:

Can we restrict HEART to use cases where a resource is only protected by
one authorization server?

Justin:

I agree.

Eve:

I think that?s really reasonable. We know about IT that?s creaky. We
shouldn?t be profiling anything that isn?t in the protocols we?re profiling.

Debbie:

In doing implementations, we might be able to inform standards an update
profiles.

Sarah:

Just to be clear, we are all in agreement that we will restrict HEART to
use cases where a resource is only protected by one authorization server?

Glen:

Within the domain? In the IRB case, we would have an authorization server.

Justin:

That?s fine as long as we use separate resources.

Glen:

I agree.

Debbie:

The data might be replicated and the IRB might acknowledge that the patient
has it?s own authorization server, but may replicate those authorizations
locally.

Glen:

Let?s not try to address keeping data in sync.

Aaron:

So we have two resource types defined, one for an individual, and another
for multiple individuals in one data set

Glen:

Right, and that could be authorization for subsequent access.

Adrian:

But there?s only ever one authorization server associated with one resource

Justin:

Resources that are addressable.

Aaron:

I run an Accountable Care Organization. I have three pieces of software.
Each is a separate data source. I can aggregate them and protect them with
one AS. I can?t protect one set of data with three ASs.

Aaron:

FHIR has single and bulk resource types. Are they in the FHIR specs?

Sarah:

Just do a text search for ?user? and ?patient?

Justin:

Actually, they are in the SMART on FHIR, not the vanilla FHIR specs.

Adrian:
SMART is trying to work out the EHR to EHR use cases. We can help as we
make progress on that.

Sarah Squire
Engage Identity
http://engageidentity.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=CxQsIGOxvi44tOe7_wVQhNOxOyMiSW3tHY0vPFelKSY&e=> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/201a04e4/attachment-0001.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_201a04e4_attachment-2D0001.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=RcZ-Ks63ou-TgDRKNfpXNvznxgVA1ABci_f1dP93w_I&e=> >

------------------------------

Message: 3
Date: Mon, 21 Dec 2015 17:59:12 -0500
From: "Aaron Seib" <aaron.seib at nate-trust.org>
To: "'Sarah Squire'" <sarah at engageidentity.com>,
        <openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
Message-ID: <038e01d13c43$35a66df0$a0f349d0$@nate-trust.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=pDZd6kP_exobhCY6W01e6vmQ7u9SRtITAKIh_2G-OIk&e=> >
Content-Type: text/plain; charset="utf-8"

I am hoping that this is helpful to others.



I think we are a work group divided by a common language at this point and maybe if we could get some concrete terms in place that relate to something for those of us who are at a loss when it comes to how some of the terms being used in various ways by different participants on the call (in what seem to be different ways probably because of the inexperience with the terms on my part anyhow) we might be able to accelerate a common set of terms.



I wrote this to try to ascertain if my understanding of the discussion about assuming a single AS for a given RS was correct and why.  I also wanted to try to peel back the onion as far as the difference between an RS that related to multiple people (called Bulk Access for some unknowable reason as far as I am concerned) versus an RS that is constrained to a single person.  And to see if I am even in the right neighborhood when it comes to understanding the relationship between a URI and the use of the Term Resource Server.



Please annotate, hyperlink, cross out or otherwise correct the attached and help me learn.



Thank you,



Aaron



Aaron Seib, CEO

@CaptBlueButton

 (o) 301-540-2311

(m) 301-326-6843





From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Sarah Squire
Sent: Monday, December 21, 2015 5:00 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21



Attendees:



Debbie Bucci

Sarah Squire

Justin Richer

Eve Maler

Glen Marshall

Aaron Seib

Kenneth Salyards

Brandon Smith

Adrian Gropper

Thomas Sullivan

Dale Moberg



Group consensus decision: we will restrict HEART to use cases where one resource is only protected by one authorization server



Glen:

I?ll be working on my use case for quick discussion in January.



Debbie:

Should we talk about one or more authorization servers?



Aaron:

It seems like sometimes HEART gets bogged down in things that would be better served by a policy group.



Glen:

I was trying to find the boundaries between specs and policy.



Aaron:

The API task force is dependent on the HEART group



Glen:

We need to consider the practical operations to move toward a better standardized technology



Aaron:

is there a difference between our approach to an individual as opposed to more than one person? We just need to serialize it.



Justin:

What do you mean by serialize it? The fact that it is being transmitted means that it?s by definition serialization.



Aaron:

I just meant we should go through the list one thing as a time.

Eve:

Are you talking about separating the data so that it?s about one person?



Aaron:

That?s the way I understand a person would do it.



Eve:

We could take the approach that if we?re patient-centric, then back channel transfer of data about multiple-people. Should multiple people be out of scope?



Debbie:

Except when the multiple people are ?my family.?



Justin:

It?s in scope in our existing use cases.



Adrian:

Once we allow for multiple patients in a resource, a lot of people who are not as sophisticated are going to bundle discovery. The caregiver has nothing to do with discovery. As soon as you get to the user having role-based access, then there?s a discovery process.



Sarah:

Why wouldn?t you know what?s on the list?



Adrian:

If there?s a list, you need discovery



Justin:

There?s no discovery



Adrian:

>From the client?s perspective, how does it know which authorization server to talk to?



Sarah:

There?s only one authorization server involved in this transaction



Aaron:

How do we comply with laws saying that medical records of wives should not be disclosed to abusive husbands?



Sarah:

By virtue of this system being patient-centered, the patient can control access to her data.



Justin:

The resource server can deny an access token for any reason, so you could do it that way.



Glen:

If we had a case where there were multiple ASs, it would be possible to have a resource server prepared to interpret all of those rules, some of which may be mutually exclusive. There is no grammar for the combinatoric aspects of multiple ASs.



Justin:

There is a project working on that called XACML. It doesn?t work at all.



Glen:

XACML doesn?t handle policies coming out of left field like the domestic violence policy.



Adrian:

Why not work with the UMA we have now rather than involving this complicated problem?



Glen:

I agree. What I was trying to get to is that there is a class of use cases that we shouldn?t be dealing with.



Justin:

I agree there?s a class of use cases that we don?t have the right tools for.



Glen:

In clinical research, we often grab bulk data, so solving for that is helpful.



Adrian:

Is there something about UMA 1.0.1 that works for the single authorization server use case



Eve:

I cannot figure out from this conversation what the multiple records use case is a problem.



Justin:

If a bulk request includes resources with multiple authorization servers, we don?t know which AS to talk to. If we define the bulk access record so that there?s only one AS, it works fine. Or if there?s an implicit AS it?s fine. Throughout all of this, we need to be very clear on the nature of the API that?s being protected when we?re designing security profiles.



Eve:

If data is restricted but then aggregated, is that still UMA?



Justin:

That?s out of scope. That?s a cache consistency problem.



Eve:

But we can do it with chained delegation.



Debbie:

Do they have to be in the same domain?



Eve:

They just have to be in the same ecosystem



Eve:

We?re talking about data portability of metadata. A resource set identifier is metadata that?s sensitive information that an AS knows about a user. You?d have to share it with another AS to be portable across networks. So we?re talking about something that I?ve worked on. It?s good that we?re talking about it. It?s not trivial for privacy or portability.



Sarah:

It sounds like it?s not fully baked enough to be within scope for HEART, correct?



Eve:

Correct.



Adrian:

Can we restrict HEART to use cases where a resource is only protected by one authorization server?



Justin:

I agree.



Eve:

I think that?s really reasonable. We know about IT that?s creaky. We shouldn?t be profiling anything that isn?t in the protocols we?re profiling.



Debbie:

In doing implementations, we might be able to inform standards an update profiles.



Sarah:

Just to be clear, we are all in agreement that we will restrict HEART to use cases where a resource is only protected by one authorization server?



Glen:

Within the domain? In the IRB case, we would have an authorization server.



Justin:

That?s fine as long as we use separate resources.



Glen:

I agree.



Debbie:

The data might be replicated and the IRB might acknowledge that the patient has it?s own authorization server, but may replicate those authorizations locally.



Glen:

Let?s not try to address keeping data in sync.



Aaron:

So we have two resource types defined, one for an individual, and another for multiple individuals in one data set



Glen:

Right, and that could be authorization for subsequent access.



Adrian:

But there?s only ever one authorization server associated with one resource



Justin:

Resources that are addressable.



Aaron:

I run an Accountable Care Organization. I have three pieces of software. Each is a separate data source. I can aggregate them and protect them with one AS. I can?t protect one set of data with three ASs.



Aaron:

FHIR has single and bulk resource types. Are they in the FHIR specs?



Sarah:

Just do a text search for ?user? and ?patient?



Justin:

Actually, they are in the SMART on FHIR, not the vanilla FHIR specs.



Adrian:

SMART is trying to work out the EHR to EHR use cases. We can help as we make progress on that.




Sarah Squire

Engage Identity

 <http://engageidentity.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=AjcfcOGb6aPlxC9Dyt5Clm5ru4kbEH5M84Cim_PMmJ4&e=> > http://engageidentity.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=CxQsIGOxvi44tOe7_wVQhNOxOyMiSW3tHY0vPFelKSY&e=> 

  _____

No virus found in this message.
Checked by AVG - www.avg.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=3FiaS6joAsU5RQNjEGx8JYSBcgQiidL0ZcwNgt0iKBE&e=> 
Version: 2016.0.7294 / Virus Database: 4489/11199 - Release Date: 12/17/15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=r2Ehy90DGAacU74nJiDvYzrFoIfQJmJYFB8pIrxL9Co&e=> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment.jpg <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.jpg&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=YbPeX-bgHZMQrDxs-N3_zgsSggwilvqra-raR65lFr4&e=> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Seib's grasp of the discussion so today.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 22067 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment.docx <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.docx&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=B8_6NwzDxXVlM-BVLrGDHBCHYhOCgSHasvbWmW1BJ2U&e=> >

------------------------------

Subject: Digest Footer

_______________________________________________
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=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=EBTeu4GenY3ZNO2bT1MReiyrcyRL9X3ktfT3byPwWr0&e=> 


------------------------------

End of Openid-specs-heart Digest, Vol 52, Issue 1
*************************************************

 

  _____  

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

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


More information about the Openid-specs-heart mailing list