[Openid-specs-heart] Vectors of Trust and the Binding Ceremony

Wed May 13 14:25:03 UTC 2015

Regarding conveying authn context at run time, each SSO protocol tends to
have its own way of encapsulating that information. So SAML has its
authentication context class reference mechanism, and OIDC has its own. UMA
on the wire has a way to ask to elevate trust based on either
authentication (which could use all this acr stuff) or claims-gathering
("claims-based access control").

The UMA Binding Obligations approach potentially enables the interacting
parties to specify contractual clauses that take effect at specific
run-time junctures, for example, when Alice's authorization server
successfully issues a token and authorization data to Bob and his client
based on Bob having "qualified in" for access. If we write into a HEART
profile that there's a requirement for certain credentialing/authentication
standards to get access to some type of resource, then this implies some
work for an access federation trust framework layer to do. The Binding
Obligations approach is one way to express that layer.

*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 Tue, May 12, 2015 at 1:47 PM, Debbie Bucci <debbucci at gmail.com> wrote:

> I trust my social account to support many facets of my private life and if
> forced to use a separate username/pwd the public identifiers that point to
> my email and cell phone are captured anyway..   Also trained to respond to
> SMS text and have a number of questions I answer on a regular (somewhat
> annoying) basis for banking.  So I kind of align with Jeremy's thinking re:
> social identity although I would say  social identity + some other factor
> (id proofing or cell num or SMS or biometric ) may give greater confidence
> in the social credential being used.  That aligns with trust elevation ...
> which is part of VOT's yet to be determined calculus and kind of leads to
> Bill's questions
>
> So the question is, what are Alice’s options assuming she wants to use SSO
> between her PHR and the PCP portal?
>
> ·        How does OpenId Connect transmit equivalent of the VoT concept
> of “P1.C3.A2”?
>
>      .... What is the equivalent of SAML authNcontext?  I know I've asked
> this several times but I have brain freeze to the answer.   I thought it
> was UMA binding obligations .
>
> ·        Map her credentials between systems?
>
> That's often how its done today.   There is a mapping between the internal
> account info the 3rd party credential and some type of binding ceremony is
> done to validate the mapping.
> ·        Elevate her PHR login (credentials )?
>
> Well if the PHR can support mulit-factor - I would suggest if used its
> more secure than the username and password used alone.    How can does the
> evidence that an in person person proofing  (that met some standard
> workflow) was performed get registered for use elsewhere?  Is it in the
> binding obligations?
> Could the patient authorization service - in this case I think its the
> PHR, provide adequate information for a resource server to make that
> determination .... I think this is where trust marks come in to play.
>
> I guess this would open another discussion as to what
> credentialing/authentication standards should HEART support to support
> interoperability?
>
> 800-63-2 for now
>
>
>
>
>
> On Tue, May 12, 2015 at 3:33 PM, Kinsley, William <BKinsley at nextgen.com>
> wrote:
>
>>  I liked that Justin’s first e-mail broken this down into pieces that
>> help me understand what he is advocating. However, at the same time opening
>> a hundred rabbit holes to fall intoJ
>>
>>
>>
>> I have two questions to start with:
>>
>>
>>
>> To address one misunderstanding, in the use case, Alice’s PHR supports *two-factor
>> authentication* while the PCP system doesn’t; however, the PCP portal
>> provides stronger proofing then Alice’s PHR does. Ideally Alice would want
>> to manage everything including her credentials and profiles from her PHR.
>>
>>
>>
>> So the question is, what are Alice’s options assuming she wants to use
>> SSO between her PHR and the PCP portal?
>>
>> ·        How does OpenId Connect transmit equivalent of the VoT concept
>> of “P1.C3.A2”?
>>
>> ·        Map her credentials between systems?
>>
>> ·        Elevate her PHR login (credentials )?
>>
>>
>>
>> So is this possible today with OpenId/oAuth/UMA?  If so, how? If not,
>> what is required?
>>
>>
>>
>> Second:
>>
>> While I like and generally agree with the concept that VoT is proposing,
>> from my understanding, VoT is not a standard today; but a IETF discussion
>> to perhaps become a standard in the future.
>>
>>
>>
>> I guess this would open another discussion as to what
>> credentialing/authentication standards should HEART support to support
>> interoperability?
>>
>>
>>
>> Bill
>>
>>
>>
>>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Sarah Squire
>> *Sent:* Tuesday, May 12, 2015 11:47 AM
>> *To:* Maxwell, Jeremy (OS/OCPO)
>>
>> *Cc:* openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Vectors of Trust and the Binding
>> Ceremony
>>
>>
>>
>> The problem is not that social credentials are insecure. The problem is
>> that users often don't trust them. I think the idea here, as in NSTIC in
>> general, is that users should be able to use their chosen Identity Provider
>> (IdP). This creates a market for IdPs that incentivizes them to get better.
>>
>>
>>
>> That said, because users don't pay for social IdPs, they are in a
>> different class legally. Social IdPs are much more loosely regulated in
>> terms of notification and consent than an IdP with a financial relationship
>> with the user, like a bank, university, or employer.
>>
>>
>>
>> On Tue, May 12, 2015 at 7:51 AM, Maxwell, Jeremy (OS/OCPO) <
>> Jeremy.Maxwell at hhs.gov> wrote:
>>
>>  Why is a social credential a bad credential for authenticating to a
>> patient portal?  For many individuals, the private details of their social
>> accounts may be held *more *privately than their health records.  There
>> are a few celebrities that wish their iCloud accounts were more secure.
>> Gmail allows for 2fx authentication if users want it.  What about if/when I
>> can sign into my Microsoft Live account using facial recognition in Windows
>> 10?  Assume there existed a strong identity proofing method that is able to
>> bind my social credential to my identity in the portal.  Would allowing
>> individuals to use a social credential (for authentication to the portal)
>> after this point be insecure?
>>
>>
>>
>>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
>> *Sent:* Monday, May 11, 2015 8:12 PM
>> *To:* Justin Richer
>> *Cc:* openid-specs-heart at lists.openid.net
>> *Subject:* Re: [Openid-specs-heart] Vectors of Trust and the Binding
>> Ceremony
>>
>>
>>
>> The VOT work is really exciting, and Justin's description of it -- and
>> the vulnerabilities lurking in locally managed accounts that often go
>> unremarked -- is very helpful and on-point. Though "social" identities
>> are perhaps not the best choices for logging in to patient portals, the
>> social-style login pattern works perfectly well, and need not increase risk.
>>
>>
>>
>> BTW, if folks haven't noticed, there's a new OpenID Foundation work group
>> called "RISC <http://openid.net/wg/risc/>" (Risk and Incident Sharing
>> Coordination) to enable event notifications around compromised accounts, so
>> that, e.g., a gmail.com confirmation loop compromise won't infect
>> additional accounts. I believe that efforts like this will ultimately have
>> more powerful impacts than all the password policies in the world. :-)
>>
>>
>>
>> *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 Mon, May 11, 2015 at 4:30 PM, Justin Richer <jricher at mit.edu> wrote:
>>
>> Swap 4 and 6 and it still works, but fed is simpler for Alice so she'll
>> probably stop there.
>>
>>
>>
>> On 5/11/2015 7:27 PM, Debbie Bucci wrote:
>>
>>
>>
>> How will that simplify the current Federation process - maybe I'm asking
>> how is the actual binding to the system performed:
>>
>> Current process often adds additional steps but you can get there
>>
>>
>>         1. Alice shows up at her doc’s
>>         2. Alice shows her ID and insurance card, these get verified
>>         3. A record gets created for Alice in the system
>>         4. The system issues Alice  a new username and password  - or one
>> time link (likely bounced through her external personal email address from
>> it-doesn’t-matter-where)
>>
>>         5. Alice logs in
>>         6. Alice now given the option to use alternative (in person) with
>> her personal digital identity (from it-doesn’t-matter-where as long as it
>> registered in system's the metadata) and this is bound to her account
>> (will assume via some session context switch )
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 11, 2015 at 6:11 PM, Justin Richer <jricher at mit.edu> wrote:
>>
>> The Vectors of Trust work that I mentioned on today’s call is, at its
>> heart, an effort to take the different aspects of a “level of assurance” as
>> defined in MB-0404 and SP-800-63 and break them apart into individual
>> components so that they can be considered separately. What’s driving this
>> is that one of the biggest problems in the wild of 800-63 is that it
>> conflates the strength of the credential with the strength of the proofing
>> (among other things), such that it doesn’t make sense within that context
>> to have an anonymous credential with a high level of assurance. This is
>> probably fine if you’re the government doing background checks on people
>> before you hand out PKI cards to its employees and contractors, but not
>> only are there other use cases out there (to which 800-63 has time and
>> again be erroneously applied) but also technologies have advanced
>> significantly in the last decade.
>>
>> So in VoT we propose to break out identity proofing, credential
>> strength/binding, and assertion strength. These names and categories are
>> still up in the air, but the concept is that there are different parts that
>> need to be communicated separately. So instead of something coming across
>> the wire as “LOA2”, it could come across as “P1.C3.A2”, which translates to
>> “proofed at level 1, credentialed at level 3, asserted at level 2”. Now the
>> question is: what does the RP do with this information? Well that depends
>> on who’s claiming it, and that’s where the trust framework and trustmark
>> efforts come into play. These will serve as the anchor for the IdP to
>> assert any particular vector, and the trust framework itself will let the
>> RP know what it can do with that information.
>>
>> The list is here and the archives are available online:
>>
>>   https://www.ietf.org/mailman/listinfo/vot
>>
>> And to pull the curtain back a bit, I’m currently working on an update to
>> my initial proposal now, with intention that it be discussed at the next
>> IETF meeting in Prague. It’s not (yet) an IETF working group, so we’re
>> still figuring out exactly where this is going to ultimately land.
>>
>>
>>
>> As to the identity binding ceremony, it really fits in with what I’m
>> discussing above: the proofing that is done at Alice’s IdP doesn’t really
>> matter if Alice is doing some higher value proofing at her doctor’s office
>> already. So what we’ve got today is something like:
>>
>>         1. Alice shows up at her doc’s
>>         2. Alice shows her ID and insurance card, these get verified
>>         3. A record gets created for Alice in the system
>>         4. The system issues Alice a new username and password (likely
>> bounced through her external personal email address from
>> it-doesn’t-matter-where)
>>
>> What I’m suggesting here is that we can use the identity federation
>> technology to replace the last part of this, to:
>>
>>         1. Alice shows up at her doc’s
>>         2. Alice shows her ID and insurance card, these get verified
>>         3. A record gets created for Alice in the system
>>         4. Alice logs in (in person) with her personal digital identity
>> (from it-doesn’t-matter-where) and this is bound to her account
>>
>>
>> Alice’s proofing is done in person so the IdP doesn’t need to do that.
>> It’s nearly guaranteed to be a better security profile than giving Alice
>> another password to manage, for many reasons I won’t enumerate on here
>> right now because the internet would run out of bits for my email. It’s
>> going to be a much better user experience for Alice, who can use a familiar
>> account to manage things. So are Alice’s attributes worthless? Hardly! The
>> medical system is still going to want things like Alice’s display name and
>> email address, for its own uses, and the IdP can provide these as inputs,
>> with Alice making sure they’re what she wants in the system. Otherwise,
>> remember, Alice is just going to be filling out the “sign up” form herself
>> anyway. The important thing is that the digital identity (the iss/sub
>> pairing in OIDC) is tied to a specific set of rights that include a
>> specific medical record (or set of records).
>>
>>
>> Now some people get all scared about talking to external IdPs, but it’s
>> important, I believe, to point out that in the first case, Alice is
>> probably going to do some kind of reset password link through her email
>> address. Which means that anyone who manages to 0wn Alice’s gmail account
>> can now reset her password and log into her medical record. This turns out
>> to be the same security profile as the second case, except that now Alice’s
>> IdP can *also* look for suspicious activity of someone using her account at
>> her medical office. The explicit account binding ceremony lets both sides
>> see clearly what’s up.
>>
>>
>> As such, what I’m suggesting here (and in the VA-based “Steve” use case
>> on the wiki) is that identity federation really does buy us a lot, and
>> notions of “Alice needs a High LoA” really don’t make sense when you pull
>> things apart. What we need to continue doing, in HEART, is to break things
>> down into their components and re-build them into the right systems for the
>> world. The use cases can help guide us to what those pieces are, but
>> remember that they don’t dictate what the systems will be.
>>
>>  — Justin
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150513/41df1d32/attachment-0001.html>