[OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal

Tue Feb 14 20:00:08 UTC 2012

At the time the profile was authored the interpretation of SP-800-63 was that the assertion could not be passed through the browser unencrypted.  

The SAML 2.0 Web SSO required that assertions sent from the IdP to the RP be encrypted.

The other method that was allowed in SP-800-63 was a authenticated direct connection between the IdP and RP,  sometimes refers to as artifact binding (think OAuth 2 code flow).

Both methods protect the assertion from being MTM or otherwise leaked by the browser.

Subsequent to that based on an updated SP-800-63 the SAML profile was changed to allow the SAML POST response binding with only TLS on the endpoints and no assertion encryption. (xmlenc with CBC is broken anyway)

I blogged about the change several weeks ago http://www.thread-safe.com/2012/01/ficam-saml-20-web-sso-profile-updated.html

There is a backstory to this, I will leave it to others to wonder why the change happened.

Suffice to say the reason openID 2.0 was rejected at LoA 2 is no longer valid under the updated interpretation of SP0-800-63. 
I am focusing on openID Connect right now, so don't think there is much to be gained going back and fighting the openID LoA 2 battle again.

If others want to press NSTIC/FICAM to reconsider openID at LoA 2 then go for it.

The system is not always reasonable.  You need to pick your battles.

Regards
John B.

On 2012-02-14, at 4:42 PM, Francisco Corella wrote:

> John,
> 
> > The thing that stopped openID 2.0 from being SP-800-63 LoA2 was the
> > lack of protection of assertions from the Identity provider to the RP
> > (No encryption or TLS protected direct communication)
> 
> In the FICAM profile of OpenID 2.0, which you co-edited, I believe the
> assertions are sent with TLS protection from the IdP to the browser
> and from the browser to the RP.  I realize that's indirect rather than
> direct communication.  But why the insistence on direct communication?
> The browser has to be trusted anyway.
> 
> Francisco
> 
> From: John Bradley <ve7jtb at ve7jtb.com>
> To: Peter Williams <home_pw at msn.com> 
> Cc: openid-general at lists.openid.net 
> Sent: Tuesday, February 14, 2012 9:30 AM
> Subject: Re: [OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal
> 
> Peter,
> 
> The thing that stopped openID 2.0 from being SP-800-63 LoA2 was the lack of protection of assertions from the Identity provider to the RP (No encryption or TLS protected direct communication)
> The thing that also stops it from being LoA 3 is a lack of asymmetric signatures for non repudiation.
> 
> Support for PKI as the primary authenticator is the same for both openID 2 and SAML 2, and not one of the considerations.
> 
> OpenID Connect http://openid.net/connect/  which is currently being voted on by the membership as an implementers draft addresses both issues.
> 
> One might reasonably expect that once openID Connect is an approved specification FICAM will produce a profile of it, perhaps upto LaA 3 non Crypto or LoA 4 with Holder of key.
> 
> There is also a openID Connect interop currently taking place amongst a number of the open source implementations http://osis.idcommons.net/wiki/OC3_OpenID_Connect_Interop_3.
> 
> Foundation Members should read the proposed spec and vote for or against it as an implementers draft.
> 
> The reason for the implementers draft is that it locks in the IPR contributions of all the contributors (Google, MS, Facebook, and Me etc).
> It also allows people to work on implementations without the spec changing weekly.
> 
> There will likely still be some changes from the implementers draft to the final version based on testing feedback.
> 
> We have been working on the specification in the openid-ab WG for several hers now so this should not be a big sup prise to anyone.
> 
> Regards
> John B.
> On 2012-02-14, at 2:09 PM, Peter Williams wrote:
> 
> > 
> > Well that was interesting.
> > 
> > 
> > 
> > The shibolleth folks managed to setup a somewhat false distinction, 2+ years ago, with the help of several UK academics, to establish that the "protocol" of openid (v1 or v2) was inherently limited to LOA1 - by design nature. One sees this division BUILT IN to the ETSI work on nationa-id cards for future-telco, very clearly. Becuase SAML2 CAN be used with PKI, it was able "uniquely" to claim a space of being LOA2+ capable.
> > 
> > 
> > 
> > NOw we learn that "openid connect" is not openid-2 (with bells and whistles). its an LOA2-capable definition, per se. Not knowing what openid connect is, I cannot really comment... In our space, we are still considering whether to turn on openid as-is (via the Microsoft STS bridge for websso protocols). openid as conceived is almost viable (now), to boostrap a professional agency/representation relationship.
> > 
> > 
> > 
> > This move-up to LOA2 is going to restart a SAML2 war, since openid is not staying in its place (supporting blogging comments, and logon to a billion sites that "dont matter" - a phrase that is (c) UK academia).
> > 
> > 
> > 
> > of course the distinction was false all along, but such are government programs - full of falseness and pretense and day-by-day political hashes. Its hard talking 2 storys out of your mouth at the same time - but thats what governing (and pre-competitive funding) is often all about. 
> > 
> > 
> > 
> > Perhaps folks here should all disclosure their "review" and 'influence" roles in the NSTIC program. John is quite open and fair and fully disclosed (if with a 6 month delay, so some proper use of FOUO can create effective working conditions for program management). Im not sure about others.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >                          
> > _______________________________________________
> > general mailing list
> > general at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
> 
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120214/4d5c8189/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120214/4d5c8189/attachment.p7s>