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

[Adrian Gropper]

John B's interpretation suggests that Section 5 is unclear. I did not read
this section as suggestion that any particular "Trust Framework" must or
should be used. I read it as simply saying that the OpenID Provider must
label their particular authentication level according to a common
definition with no particular framework implied.

Adrian

On Sat, Nov 28, 2015 at 12:14 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> The FICAM acr values may be fine for the US but are probably not going to
> be used directly by other countries, and even in the US that implies having
> a FICAM certification to be able to meaningfully assert as a IdP.   That
> might happen in the US but probably not in the UK etc.
>
> We could say "(FICAM) Trust Framework, or equivalent Trust Framework
> SHOULD be used”.
>
> In other words use known and preferably
> https://tools.ietf.org/html/rfc6711 registered values.
> It might be useful to add a reference to the LoA registry and ask GSA/NIST
> to register the FICAM LoA.
>
> The last one rather then being a conversational must would be better as
> SHOULD.
> It may not be practical for IdP to get agreement from all RP,  using a
> documented set of values is probably sufficient.
>
> I think Mile Jones was going to set up a IANA registry for that, but I
> don’t have a reference at hand.
>
> John B.
>
> On Nov 28, 2015, at 1:36 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>
> 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
>>
>>
> _______________________________________________
> 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
>
>


-- 

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