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

John Bradley ve7jtb at ve7jtb.com
Sat Nov 28 20:33:36 UTC 2015


The FICAM Trust framework referenced is a Trust Framework is a Government trust framework http://www.idmanagement.gov/trust-framework-solutions <http://www.idmanagement.gov/trust-framework-solutions>
That identity providers for the US Federal Government must be certified against.

The goal of the eGov WG is to use this document as part of defining a profile of Connect that FICAM can use to define “Adopted Identity Scheme” for OpenID Connect.

So it is a bit premature to be tying this document to FICAM.   The FICAM LoA URI are not generic, they apply to that specific trust framework, certification and legal agreements.

Profiles using this should be specifying specific trust frameworks for there jurisdictions/communities of interest.

John B.

> On Nov 28, 2015, at 2:57 PM, Adrian Gropper <agropper at healthurl.com> wrote:. 
> 
> 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 <mailto: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 <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 <mailto: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 <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 <tel:%2B1%20425.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 <mailto: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 <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 <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 <http://openid.bitbucket.org/HEART/openid-heart-oidc.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 <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 <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>
> 
> 
> 
> 
> -- 
> 
> 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/ <http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151128/6b9a5c27/attachment.html>


More information about the Openid-specs-heart mailing list