[Openid-specs-heart] Health Relationship Trust Profile for OAuth 2.0

[John Bradley]

Yes it probably should be separate instances of client software.    I don’t know that “of a given piece” adds much to the sentence.  

OAuth 2 allows for non confidential clients to use the code flow.  The client credential is optional. This is not as secure as it would be with a confidential client.

We now have the PKCE extension for OAuth that improves the security for non confidential clients using code flow, but that has become a RFC only after this profile was created.

This profile is forcing every client instance to dynamically register (3) so that it has it’s own asymmetric key pair provisioned. 

I think that is fine for this profile.

John B.



> On Nov 28, 2015, at 1:34 PM, Eve Maler <eve.maler at forgerock.com> wrote:
> 
> An example could go a long way here. The usual concern is that a mobile application has been assigned client credentials "at the factory", and every copy ("instance") downloaded at the App Store carries the exact same credentials -- that is, it's a kind of clone. (I'm writing this without having looked at the phrase in context, so I'm not sure if that's what was meant...)
> 
> 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 Sat, Nov 28, 2015 at 12:29 AM, Danny van Leeuwen <danny at health-hats.com <mailto:danny at health-hats.com>> wrote:
> 2.1.1. <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.2.1.1> Full Client with User Delegation <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#FullClient>
>  
> From <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html>>
> The authorization code flow is supported only for confidential clients. Examples of this client type include web applications and native applications that can store installation-instance-specific client credentials securely. Client credentials MUST NOT be shared among instances [separate or discreet instances?] of a given piece of client software.
>  
> From <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html>> 
> 
> -- 
> Danny van Leeuwen
> 617-304-4681 <tel:617-304-4681>
> 
> Blog www.health-hats.com <http://www.health-hats.com/> discovering the magic levers of best health
> Twitter @healthhats
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <mailto: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>
> 
> 
> _______________________________________________
> 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/20151128/e474d91e/attachment.html>