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

Mon Nov 30 15:18:54 UTC 2015

And only when we try and let things break will we learn what will work in the real world involving all the different members of the community.

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Sunday, November 29, 2015 9:34 PM
To: John Bradley
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Health Relationship Trust Profile for OpenID Connect 1.0

Ultimately this work should all be referencing VoT and not LoA, but that wasn’t nearly as baked when the document was originally written.

I’m happy to put in alternate values here. Remember that this is an implementers draft, and things can and will break.

 — Justin

On Nov 28, 2015, at 3:33 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

The FICAM Trust framework referenced is a Trust Framework is a Government trust framework 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> 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 <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> 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#rfc.section.5> 5.  <http://openid.bitbucket.org/HEART/openid-heart-oidc.html#AuthenticationContext> Authentication Context

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/> http://patientprivacyrights.org/donate-2/ 

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7227 / Virus Database: 4477/11090 - Release Date: 11/29/15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151130/26857dd4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3141 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151130/26857dd4/attachment.jpg>