[Openid-specs-heart] Health Relationship Trust Profile for OpenID Connect 1.0

[Eve Maler]

A "relying party" is a term of art in the OIDC spec, and is defined up
front, so I think we're okay there:

http://openid.net/specs/openid-connect-core-1_0.html#Terminology
"Relying Party (RP)
OAuth 2.0 Client application requiring End-User Authentication and Claims
from an OpenID Provider."

Regarding the should/SHOULD and must/MUST, good questions!



*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:11 AM, Danny van Leeuwen <danny at health-hats.com>
wrote:

> 1 question
>
> 2 words that might need to be capitalized
>
>
> Otherwise the grammar is good.
>
> Abstract
> <http://openid.bitbucket.org/HEART/openid-heart-oidc.html#rfc.abstract>
>
> The OpenID Connect protocol defines an identity federation system that
> allows a relying [what is  a relying party?] party to request and receive
> authentication and profile information about an end user
>
>
>
> From <http://openid.bitbucket.org/HEART/openid-heart-oidc.html>
>
>
>
> 5.
> <http://openid.bitbucket.org/HEART/openid-heart-oidc.html#rfc.section.5> Authentication
> Context
> <http://openid.bitbucket.org/HEART/openid-heart-oidc.html#AuthenticationContext>
>
> OpenID Providers MUST provide acr (authentication context class reference,
> equivalent to the Security Assertion Markup Language (SAML) element of the
> same name) and amr (authentication methods reference) values in ID tokens.
>
> The standardized Uniform Resource Identifiers (URIs) established by the
> Federal Identity, Credential, and Access Management (FICAM) Trust Framework
> should [SHOULD?] be used for the acr values, depending on the Level of
> Assurance (LOA) of the authentication performed by the OpenID Provider:
>
>
>
> From <http://openid.bitbucket.org/HEART/openid-heart-oidc.html>
>
>
>
> The amr value is an array of strings describing the set of mechanisms
> used to authenticate the user to the OpenID Provider. Providers that
> require multi-factor authentication will typically provide multiple values
> (for example, memorized password plus hardware-token-generated one-time
> password). The specific values must [MUST?] be agreed upon and understood
> between the OpenID Provider and any Relying Parties.
>
>
>
> From <http://openid.bitbucket.org/HEART/openid-heart-oidc.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/4967c0e7/attachment.html>