[Openid-specs-heart] Pulling out Native Apps

Justin Richer jricher at mit.edu
Tue May 31 20:16:55 UTC 2016


Dynamic registration is still a MUST for the AS to support as it allows runtime on boarding of new clients without the involvement of sysadmins or other technical acumen. 

To Debbie’s question, dynamic registration has never been a MUST for clients to use, however. So for single-AS systems with public clients, this might make sense to profile separately.

That doesn’t help us with the multi-AS world, which is likely to occur with clients speaking to the same API deployed across different systems, nor does it help with key management, so we’ve got to handle this carefully.

 — Justin

> On May 31, 2016, at 4:05 PM, 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 <mailto:gfm at securityrs.com>
> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>  
> From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
> Sent: Tuesday, May 31, 2016 16:03
> To: Glen Marshall [SRS] <gfm at securityrs.com>
> Cc: Debbie Bucci <debbucci at gmail.com>; Justin Richer <jricher at mit.edu>; 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 <mailto: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 <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/ <http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160531/dc7935a2/attachment.html>


More information about the Openid-specs-heart mailing list