[Openid-specs-heart] Pulling out Native Apps

[Adrian Gropper]

The patient experience. The current way I need to get OAuth key to
grant access to my resources on the Google API is not user-friendly. I need
my HEART resource servers like Google and Mass. General Hospital to support
dynamic registration of _any_ clients that my HEART Authorization Server
chooses to allow.

To put it another way, once I register my AS with the RS, the AS is
delegated full control over what clients can access the resource and I
should not have to log into the RS patient portal again (unless I chose to
use a different AS). This is consistent with the recommendations of the API
Task Force.

Adrian

On Tuesday, May 31, 2016, Glen Marshall [SRS] <gfm at securityrs.com> wrote:

> Why?
>
>
>
>
>
> Glen F. Marshall
>
> Consultant
>
> Security Risk Solutions, Inc.
>
> 698 Fishermans Bend
>
> Mount Pleasant, SC 29464
>
> Tel: (610) 644-2452
>
> Mobile: (610) 613-3084
>
> gfm at securityrs.com <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>
>
> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>
>
>
> *From:* agropper at gmail.com
> <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');> [mailto:
> agropper at gmail.com <javascript:_e(%7B%7D,'cvml','agropper at gmail.com');>] *On
> Behalf Of *Adrian Gropper
> *Sent:* Tuesday, May 31, 2016 16:03
> *To:* Glen Marshall [SRS] <gfm at securityrs.com
> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>>
> *Cc:* Debbie Bucci <debbucci at gmail.com
> <javascript:_e(%7B%7D,'cvml','debbucci at gmail.com');>>; Justin Richer <
> jricher at mit.edu <javascript:_e(%7B%7D,'cvml','jricher at mit.edu');>>;
> openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>
> *Subject:* Re: [Openid-specs-heart] Pulling out Native Apps
>
>
>
> Sorry, dynamic registration is a MUST.
>
>
>
> Adrian
>
> On Tuesday, May 31, 2016, Glen Marshall [SRS] <gfm at securityrs.com
> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>> wrote:
>
> I also agree to adding native apps.
>
>
>
> As far as use cases for them, some will map on existing web app uses.  But
> I can imagine a network connectivity hub, e.g., a medical home, connecting
> to multiple apps on behalf of multiple native apps.  Dynamic registration
> needs to be a supported option, but not mandatory in HEART’s model.  I
> wonder what this means to scalability.
>
>
>
>
>
> Glen F. Marshall
>
> Consultant
>
> Security Risk Solutions, Inc.
>
> 698 Fishermans Bend
>
> Mount Pleasant, SC 29464
>
> Tel: (610) 644-2452
>
> Mobile: (610) 613-3084
>
> gfm at securityrs.com
>
> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Debbie Bucci
> *Sent:* Tuesday, May 31, 2016 14:56
> *To:* Justin Richer <jricher at mit.edu>
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Pulling out Native Apps
>
>
>
> So does that mean dynamic registration would not apply to native apps ?
>
> Or could a device/native app/hub(?) dynamically connect for multiple apps?
>
> Agree adding adding native apps
>
> On May 31, 2016 11:54 AM, "Justin Richer" <jricher at mit.edu> wrote:
> >
> > From a conversation in our sister iGov working group, we think there
> might be a gap in the current client descriptions in HEART. Namely, native
> applications aren’t called out as being separate from web-based clients.
> Newer techniques like PKCE can allow native apps to connect more securely
> without per-instance registration, and software statements are going to be
> particularly important for these clients as well. There’s some question as
> to how we’ll manage key registration here, since we don’t want to encourage
> packing the same private key in a million copies of a piece of software.
> >
> > What we’re proposing is that we separate out recommendations and
> requirements for native apps (and desktop apps) as a fourth category
> alongside the current “full app”, “in-browser app”, and “batch-process app”
> categories.
> >
> > Note that we’re not proposing, at this time, relaxing the requirement
> that the AS make dynamic registration available.
> >
> >  — Justin
> > _______________________________________________
> > 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160531/86adc602/attachment.html>