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

[Eve Maler]

To translate for the less technical among us...

While it was once common (and it may still be) for software app publishers
to use the simple "clone" approach in giving each user their own copy of an
app, technological advances have made it possible to ensure that every copy
of an app can register for its own unique credentials, and our profile can
and should take advantage of forcing this more secure method.


*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 6:01 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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
> > 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>
>> 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>
>>
>> --
>> Danny van Leeuwen
>> 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
>> 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/460dbb31/attachment.html>