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

[Eve Maler]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151128/2c33ec6a/attachment.html>