Yes. Go for Artifact Binding! <br>That happens to be the main road block for even writing CX. <br>If we had that, we could completely reuse the OpenID protocols already spec'ed out. <br>Unfortunately it is not the case. <br>
<br>Current thinking is that CX sends the AX store message to OP Endpoint in direct communication, which sounds like a bit of stretch. Is that OK from AX stand point??? <br>Hope so. See <a href="http://www.sakimura.org/en/modules/wordpress/index.php?p=89">http://www.sakimura.org/en/modules/wordpress/index.php?p=89</a> for details in Section 4, Protocol. <br>
<br>On the assertion disclosure, I do not read that requirement on NIST SP800-63. It only requires "digitally signed by trusted entity" or direct communication. (Here, "digitally signed" means signed by public key cryptography. OpenID "sign" does not qualify). <br>
<br>Which document are you referring to? <br><br>To cope with "Digital Signature" issue, we can adopt it in OpenID 2.1. Alternatively, we can profile AX so that it carries rsa-sha256 signature. <br><br>=nat<br><br>
<div class="gmail_quote">On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Complexity could be minimally increased by defining an artifact profile.<br>
<br>
Encryption using artifact profile requires no specification, comes for<br>
free by having OP SSL endpoints.<br>
<br>
Artifact profile would reduce the length of URLs, currently a problem<br>
(not all implementations seem to handle POST very well, and POST can<br>
be annoying on mobile devices or when changing from SSL to non-SSL<br>
context). I think it would be more beneficial on that basis than even<br>
from a security standpoint.<br>
<br>
Otherwise, I agree with John's assessment.<br>
<div><div></div><div class="h5"><br>
On Wed, Aug 12, 2009 at 1:32 PM, John Bradley<<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>> wrote:<br>
> Kids,<br>
> The GSA is producing a profile of standards.<br>
> OpenID 2.0, PAPE and AX are the only standards.<br>
> Surprisingly SREG 1.1 is not a standard (I guess we just forgot in our<br>
> enthusiasm for AX)<br>
> The last thing the GSA wants (as I understand it) is to create new specs and<br>
> impose them on the community. This includes picking winners and losers in<br>
> proposed extensions.<br>
> The GSA has not said that openID can never be LoA 2+ , only that given the<br>
> existing specs available to profile it doesn't meet the criteria of SP800-63<br>
> for LoA 2.<br>
> The protocol MUST prevent assertion disclosure at LoA 2.<br>
> That is the main roadblock.<br>
> Other protocols encrypt the assertion to the RP or use a direct SSL<br>
> connection (artifact binding)<br>
> It is a tradeoff that openID community needs to consider carefully,<br>
> security can be increased to meet LoA 2 but it will be at the cost of<br>
> increased complexity.<br>
> It may not be a good bargain. That however is a decision for the community<br>
> to make and not the GSA or any other government.<br>
> I don't believe that CX addresses this issue, it is intended to solve a<br>
> different trust problem.<br>
> Nat and I have discussed this.<br>
> If there is a extension to openID or changes to the core spec that allow<br>
> openID to be profiled at LoA 2+ then the GSA or whoever can revisit the<br>
> profile.<br>
> These things are not cast in stone.<br>
> Some of the things in the TFAP are a challenge the Shibboleth community as<br>
> well.<br>
> If a bank wants to send your unencrypted data through a browser as a<br>
> redirect, good for them.<br>
> The GSA and OMB have to live within SP800-63, and given that I think the<br>
> decision to profile openID for LoA 1 while the community sort out where it<br>
> wants to go is reasonable.<br>
> My opinions are my own as always, and not representative of any government<br>
> or organization.<br>
> Take a deep breath, relax it is all good.<br>
> John B.<br>
><br>
> Message: 5<br>
> Date: Wed, 12 Aug 2009 12:25:45 -0700<br>
> From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><br>
> Subject: Re: [OpenID] OpenID + Government<br>
> To: Paul Madsen <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
> Cc: "<a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>"<br>
> <<a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>><br>
> Message-ID: <<a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com">73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com</a>><br>
> Content-Type: text/plain; charset="us-ascii"<br>
><br>
> Ok!<br>
><br>
> So you did what myspace did: took the defined extension points and<br>
> added value . They discarded the dh handshake, and use a vendor<br>
> specific association protocol (apparently). Better strength and<br>
> assurance hopefully... falling back to default (low) assurance ...<br>
> when no better option can be found.<br>
><br>
> In your case, I'll guess in the endpoint xrd that you advertise - per<br>
> the model -additional extension handler names, so adding value via the<br>
> extension framework. Presumably this offers something suiting banking<br>
> frauds to only those endpoints wanting to rely on xri resolution ...<br>
> for capability negotiation and address selection (which is the more<br>
> openid way of doing things).<br>
><br>
> This is all just like ssl, now, where folks up negotiate higher<br>
> strength mechanisms and higher level operational assurances.<br>
><br>
> But look at the difference In my tone and characterization, when<br>
> discussing the assurance space.<br>
><br>
> Let's tell the ssl story using a divisive characterization of<br>
> assurances, now:<br>
><br>
> Oh my god, netscapes 40bit rc4 ciphersuite with crappy pertabators in<br>
> the kdf (broken by a French student) and verisign class 1 client certs<br>
> means ALL of ssl3 is low assurance. Look! GSA confirms it. It's a<br>
> fact! Folks must now switch to IPsec, for >loa1 assurance level when<br>
> tunelling!<br>
><br>
> No. Thats not how it was handled. Nsa/Dod comes along, puts in a missi<br>
> ciphersuite, adjusts the handshake flow so missi-style key agreement<br>
> can share the record layer with rsa handshakes, and dod office systems<br>
> get all the additional strength of missi ciphers and missi assurances<br>
> when talking amongst themselves (now featuring monthly changing user<br>
> keying material, key comprise handling, flash authority removal,<br>
> remote cac applet provisioning on gp smartcards...). They can still<br>
> interwork with public sites using rsa, at low assurance, however.<br>
><br>
> (I'm showing my out of dateness In federal systems. By now, missi will<br>
> have been renamed 6 times...)<br>
><br>
> What we want is Strong, professional security engineering, based on cc<br>
> claims, STD protection profiles, evaluated cryptomodules, even formal<br>
> methods proving the info flow properties of the strong type system,...<br>
> And in grassroots centric openid, We want that all to be developed in<br>
> and shown by common or garden programmers, not just defense<br>
> contractors working for GSA-affiliated .gov sites<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Aug 12, 2009, at 8:37 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
> wrote:<br>
><br>
> As you acknowledge ('custom extension albeit'), the application you<br>
><br>
> are<br>
><br>
> referring to supplemented OpenID's own security in order to meet the<br>
><br>
> higher assurance requirements.<br>
><br>
> With the standardization of that 'custom extension' continuing to<br>
><br>
> progress in the OpenID community, perhaps the GSA will in the future<br>
><br>
> reevaluate whether the combination can support higher assurance?<br>
><br>
> The GSA have said (or will say soon I guess) only that OpenID 2.0, as<br>
><br>
> profiled, tops out at LOA1 (for US Gov RPs). The profile doeesnt<br>
><br>
> mention<br>
><br>
> (I think at least, I havent read it) CX or any other extensions that<br>
><br>
> might supplement assurance.<br>
><br>
> paul<br>
><br>
> p.s. I believe I am as suspicious of the realty industry as you are of<br>
><br>
> Liberty<br>
><br>
> Peter Williams wrote:<br>
><br>
> So there i am in 2006 trying to let our 100k realtors use their rsa<br>
><br>
> tokencodes at lots of other websites in the realty universe.<br>
><br>
> Sounds simple, no?<br>
><br>
> And I walk into this religion style war of words, of spin meistering,<br>
><br>
> claim and counterclaim ...and a omnipresent culture of the putdown.<br>
><br>
> Generally: an intense over sensitivity, in the saml camp. And it's<br>
><br>
> not<br>
><br>
> because realty is a hot new market for websso sales!<br>
><br>
> As a lapsed security engineer, i love seeing the passion (and i also<br>
><br>
> love the saml product we selected, which we use everyday at a cost of<br>
><br>
> deployment now of about $2000 partner link (taking about 3 days, in<br>
><br>
> most cases)). But the "edginess" I see displayed across not one but<br>
><br>
> several companies is a real issue for going further with saml. I feel<br>
><br>
> like I'm stepping across a precipice.<br>
><br>
> And the edginess gets noticibly stronger the moment i talk about<br>
><br>
> (also) using openid in our customers trust networks.<br>
><br>
> Now you are a good person to challenge on the bretts topic of "GSA<br>
><br>
> has<br>
><br>
> declared openid as inherently unable to address more than loa1<br>
><br>
> assurance requirements". A firm you associate with has been using<br>
><br>
> openid (with a custom extension albeit) for banking transactions-<br>
><br>
> which are not trivial transactions for which low assurance is<br>
><br>
> appropriate.how can I reconcile those 2 statements?<br>
><br>
> Now I feel I'm being spun to even more. Brett made, in literary<br>
><br>
> analysis, a reaching for that "defining" gsa classification. And in<br>
><br>
> that act of reaching underminded his case for being impartial. A good<br>
><br>
> politician doesn't reach for the very classification device that<br>
><br>
> devides folks. He or she enables (almost magically) a acceptable<br>
><br>
> tradeoff.<br>
><br>
> Is kantara going to formally disarm the samlista brigade and move<br>
><br>
> forward, or have we just got a new name for the same old warhorse?<br>
><br>
><br>
><br>
> Grudgingly, they acceptedn<br>
><br>
><br>
><br>
><br>
> On Aug 12, 2009, at 4:10 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
><br>
> wrote:<br>
><br>
> Peter, a good theory. But you forget to mention that NORAD<br>
><br>
> intentionally<br>
><br>
> scrambled the fighters late to allow the planes to get to the<br>
><br>
> towers.<br>
><br>
> Peter Williams wrote:<br>
><br>
> My value- such as it is- is as an outsider.<br>
><br>
> I measured 4 sources:<br>
><br>
> Sun Micro rsa conference presentation on their openid pilot;<br>
><br>
> rationales for never being an rp<br>
><br>
> Ping identity factors gating speed of adoption of openid2 -<br>
><br>
> privileged acess<br>
><br>
> Scott cantors view on openid2 generally, and saml as used in xrd;<br>
><br>
> raw opinion, shared freely<br>
><br>
> How the uk jisc pilot of openid framed the basis for it's total<br>
><br>
> adoption failure in uk academia. Was it geared to fail?<br>
><br>
> Given these 4 inputs, I simply conjectured a link (liberty). I<br>
><br>
> tested my conjecture by being a bit outlandish. CoMpared to the<br>
><br>
> norm (fox news and msnbc), I was MILD in the imputations. Lots of<br>
><br>
> Ifs, buts, shoulds, mays....that mature heads would recognize as<br>
><br>
> method.<br>
><br>
> Don't get upset. It's just an experiment.<br>
><br>
> Little, powerless, clueless, skilless, informationless peter throws<br>
><br>
> tiny word stone at mighty million dollar liberty standards lobbying<br>
><br>
> machine ...and gets "over the top" reaction.<br>
><br>
> Why? Why such sensitivity?<br>
><br>
><br>
><br>
> On Aug 11, 2009, at 5:29 PM, "John Bradley"<br>
><br>
> <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>>> wrote:<br>
><br>
> Peter, Brett<br>
><br>
> As a member of Liberty, Kantara, ICF, and OIDF. I can say that I<br>
><br>
> have never seen any indication of Liberty plotting against openID<br>
><br>
> or info-card. (I do go to most of the secret meetings)<br>
><br>
> The issue with physical access is more one of not trying to boil<br>
><br>
> the ocean.<br>
><br>
> There is real desire by real government RPs to use open<br>
><br>
> technologies and work with commercial identity providers. There<br>
><br>
> are RPs I am working with who want this yesterday.<br>
><br>
> This first step is hard enough. Many people have been working hard<br>
><br>
> for many months.<br>
><br>
> One of the ways we have been able to make progress is by limiting<br>
><br>
> the scope.<br>
><br>
> We could have done physical access, LoA 4, p-cards and other<br>
><br>
> things.<br>
><br>
> The initial program by the GSA is a start not an end to the<br>
><br>
> process.<br>
><br>
> There will be changes to the initial profiles and additional<br>
><br>
> profiles as time and requirements permit.<br>
><br>
> This first step is a scary amount of work, give us time please.<br>
><br>
> John B.<br>
><br>
> On 11-Aug-09, at 5:04 PM, <mailto:<a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><br>
><br>
> <a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><br>
><br>
> wrote:<br>
><br>
> Date: Tue, 11 Aug 2009 13:43:29 -0700<br>
><br>
> From: Peter Williams<br>
><br>
> <<mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><br>
><br>
> Subject: Re: [OpenID] OpenID + Government<br>
><br>
> To: Brett McDowell<br>
><br>
> <<mailto:<a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a><br>
><br>
> Cc: OpenID List<br>
> <<mailto:<a href="mailto:general@openid.net">general@openid.net</a>><a href="mailto:general@openid.net">general@openid.net</a><mailto:<a href="mailto:general@openid.net">general@openid.net</a><br>
><br>
> Message-ID: <<mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br>
><br>
> <a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br>
><br>
> Content-Type: text/plain; charset="us-ascii"<br>
><br>
> If the infocard stack is technically reputable, can you explain why<br>
><br>
> an<br>
><br>
> accredited provider would be excluded from using it (and openid)<br>
><br>
> from<br>
><br>
> making assertions of physical presence?<br>
><br>
> _______________________________________________<br>
><br>
> general mailing list<br>
><br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net">general@lists.openid.net</a>><br>
><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
> _______________________________________________<br>
><br>
> general mailing list<br>
><br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
> End of general Digest, Vol 36, Issue 13<br>
> ***************************************<br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
<div><div></div><div class="h5">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>