<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The GSA is producing a profile of openID for the use of Gov RP.<div><br></div><div>Other organizations need to produce profiles that fit there needs.</div><div><br></div><div>One should not assume that Banking or other sectors have the same profile needs.</div><div><br></div><div>I am guessing that the Japanese Gov and others will produce there own profiles and certification practices.</div><div><br></div><div>It is the communities responsibility to design and implement the specs. </div><div><br></div><div>I understand that you want artifact binding for several reasons. </div><div><br></div><div>If it is adopted and receives implementation support the GSA and others can incorporate it into the profile.</div><div><br></div><div>John B.</div><div><br></div><div><div><div>On 13-Aug-09, at 10:38 AM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">If not being able to cope with LoA 2 or 3 becomes a barrier for adoption for even LoA 1, then it may be good to prepare it, even though nobody uses it. It is just the matter of having a spec for it. Think of it as a marketing activity. <div> <br></div><div>=nat<br><br><div class="gmail_quote">On Fri, Aug 14, 2009 at 2:32 AM, David Recordon <span dir="ltr"><<a href="mailto:david@sixapart.com">david@sixapart.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> In some senses I'm not sure if it makes sense for us to really think about LoA 2 or 3 right now or worry if it is "OpenID" if we make the changes required to meet level 3. Let's wait until we have an amazing set of deployments within the Government where OpenID can be successful today and then evolve the protocol when there is another set of absolutely amazing potential deployments that would require us to do so.<br> <br> (this might also be a better discussion on the specs@ list since general@ isn't supposed to get into nitty gritty of the tech)<br> <br> --David<div><div></div><div class="h5"><br> <br> On Aug 13, 2009, at 10:12 AM, John Bradley wrote:<br> <br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5"> Again eavesdropping mitigation is a good start for LoA 2.<br> <br> LoA 3 is not just signing, it requires chaining back to the federal trust bridge CA.<br> Remember this is about the US governments requirements.<br> <br> There are non-repudiation, and revocation requirements for the signature.<br> <br> Shibboleth and Infocard are currently working with the GSA on signing and trust chaining issues at LoA 3.<br> <br> Hopefully the road will be smother by the time openID gets to it.<br> <br> Though I do have to ask is it still openID with RSA or ECDSA signatures?<br> <br> John B.<br> <br> On 13-Aug-09, at 9:21 AM, Peter Williams wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Yes, but that means adding rsa to the core of openid (which means adding asymmetric public key management). It's no longer openid!<br> <br> For loa2, focus on the eavesdropping requirements (for both responses AND requests).<br> <br> For loa3, focus on the nr only, which means certs (or signed xrd playing the role of x509 format certs).<br> <br> <br> <br> <br> On Aug 13, 2009, at 9:00 AM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a><mailto:<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>> wrote:<br> <br> Just to add another merit for artifact, it is very mobile client friendly.<br> It is pretty simple to write a spec for it, and to implement it.<br> RSA-SHA sign, we do not have to wait until 3.0.<br> If I remember correctly, it was one of the thing to be done in 2.1 timeframe.<br> <br> =nat<br> <br> On Fri, Aug 14, 2009 at 12:55 AM, Peter Williams <<mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>> wrote:<br> if saml2 satisfies the rule, at "loa=2"and "loa=3", then we don't have to do any more than SAML2 does.<br> <br> Why not let a WG profile/amend messages, for use in 12m time, and choose suitable security mechanisms that address the fact that assertion communication is indirect (and request communication is typically indirect).<br> <br> Now, we faced what openid faces with indirect communication structures when we (Visa/Mastercard/IBM/VeriSign etc) designed SET; IBM's OAEP saved the day.<br> <br> lets reopen the WG for openid auth, for minor releases: 2.1 and 2.2. Fundamentally, lets add public key techniques to the communication plane , in the form of the OAEP. I dont know who Will is, but i'll guess he will implement OAEP in about 30m. Its just a one-time pad, and the generation/use of reversible trapdoor hash-based KDFs that generate the encryption/decryption subkey schedule of a DES-era feistel network).<br> <br> Define v2.1 as<br> 1. the simple addition of OAEP as a new "signing" method, and<br> 2. the sensitive information values in a signed assertion can now blank in the cleartext form of the assertion transferred classically, when OAEP is the signing method.<br> <br> The point is that the public association + nonces is the source keying material - that OAEP then uses to generate the one time pad that encrypts/signs the request or response under the reversible public key properties of the OAEP scheme.<br> <br> define v2.2 as<br> 1. the addition of an artifact binding mode. That is, a private association used by OPs when responding need not sign the assertion any longer, but can sign (using OAEP) a blank assertion template. (The use-once private association handle is the artifact id, itself).<br> 2. Over direct channel and existing flow, enable RP to resolve the private association (= artifactID in SAML speak). Amend verification response so its message can be optionally signed (using OAEP) using a public association, thus delivering the ciphertext of the assertion to the intended recipient as well as the status of the private association resolution (isvalid=true).<br> <br> in a v3.0, once you have signed XRD, and add RSA entity public keys (with signing keyusage only) to the (provider-signed) endpoint XRDs, we can address non-repudiation for higher levels of assuraces. One can sign the OAEP ciphertext, using RSA, where the (rsaciphertext,oaepciphertext) is put into the base64 of an openid signature type - for either requests or responses.<br> <br> ________________________________________<br> From: <mailto:<a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a>> <a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a><mailto:<a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a>> [<mailto:<a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a>><a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a><mailto:<a href="mailto:openid-general-bounces@lists.openid.net" target="_blank">openid-general-bounces@lists.openid.net</a>>] On Behalf Of John Bradley [<mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>><a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>>]<br> Sent: Wednesday, August 12, 2009 10:40 PM<br> To: Nat Sakimura<br> Cc: <mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>> <a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a><mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>><br> Subject: Re: [OpenID] OpenID + Government<br> <br> Nat,<br> <br> Look at sec 8.1.2<br> Eavesdropping resistance: An authentication protocol is resistant to<br> eavesdropping attacks if an eavesdropper who records all the messages<br> passing<br> between a claimant and a verifier or relying party finds that it is<br> impractical to<br> learn the private key, secret key or password or to otherwise obtain<br> information<br> that would allow the eavesdropper to impersonate the claimant.<br> Eavesdropping<br> resistant protocols make it impractical3 for an attacker to carry out<br> an off-line<br> attack where he/she records an authentication protocol run then<br> analyses it on<br> his/her own system for an extended period, for example by systematically<br> attempting to try every password in a large dictionary, or by brute<br> force<br> exhaustion.<br> <br> Also Table 3 on page 39 Required Protections<br> <br> Using AX update_url doesn't protect the authentication token.<br> It would send a unsolicited positive assertion to the RP return_to URL<br> with a separate token.<br> <br> Also 8.2.2.2.Assertions requires that the trusted entity(OP)<br> authenticates to the RP using a secure protocol. As the OP is<br> connecting to the RP in the AX case mutual TLS would be required.<br> <br> In AX the store message is a indirect message sorry. It is not<br> relevant to the LoA 2 case in any event as LoA 2 requires protection<br> against eavesdroppers on the reply.<br> <br> Honestly it is better to take LoA 1 now and work on LoA 2 with proper<br> planning and spec cycle.<br> <br> A lot of thought went into the decision not to hold up openID LoA 1 by<br> trying to include LoA 2 in the same profile.<br> <br> We have only covered some of the issues. Password entropy, identity<br> proofing, liability, and other issues all come into play at LoA 2.<br> <br> Getting LoA 1 approved was no cake walk itself.<br> <br> I have probably said too much as it is.<br> <br> I look forward to the GSA releasing the profile then people will have<br> something more concrete to criticize. I will happily take the heat<br> for that.<br> <br> John B.<br> <br> On 12-Aug-09, at 8:48 PM, Nat Sakimura wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> 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<br> Endpoint in direct communication, which sounds like a bit of<br> 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" target="_blank">http://www.sakimura.org/en/modules/wordpress/index.php?p=89</a>> <a href="http://www.sakimura.org/en/modules/wordpress/index.php?p=89" target="_blank">http://www.sakimura.org/en/modules/wordpress/index.php?p=89</a><br> for details in Section 4, Protocol.<br> <br> On the assertion disclosure, I do not read that requirement on NIST<br> SP800-63. It only requires "digitally signed by trusted entity" or<br> direct communication. (Here, "digitally signed" means signed by<br> 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<br> 2.1. Alternatively, we can profile AX so that it carries rsa-sha256<br> signature.<br> <br> =nat<br> <br> On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros<br> <<mailto:<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>><a href="mailto:breno@google.com" target="_blank">breno@google.com</a><mailto:<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>>> wrote:<br> Complexity could be minimally increased by defining an artifact<br> 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> <br> On Wed, Aug 12, 2009 at 1:32 PM, John<br> Bradley<<mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>><a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>>> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> our<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> enthusiasm for AX)<br> The last thing the GSA wants (as I understand it) is to create new<br> </blockquote> specs and<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> impose them on the community. This includes picking winners and<br> </blockquote> losers in<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> proposed extensions.<br> The GSA has not said that openID can never be LoA 2+ , only that<br> </blockquote> given the<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> existing specs available to profile it doesn't meet the criteria<br> </blockquote> of SP800-63<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> cost of<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> increased complexity.<br> It may not be a good bargain. That however is a decision for the<br> </blockquote> community<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> to make and not the GSA or any other government.<br> I don't believe that CX addresses this issue, it is intended to<br> </blockquote> solve a<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> allow<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> openID to be profiled at LoA 2+ then the GSA or whoever can<br> </blockquote> revisit the<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> profile.<br> These things are not cast in stone.<br> Some of the things in the TFAP are a challenge the Shibboleth<br> </blockquote> community as<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> think the<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> decision to profile openID for LoA 1 while the community sort out<br> </blockquote> where it<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> wants to go is reasonable.<br> My opinions are my own as always, and not representative of any<br> </blockquote> government<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <<mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>><br> Subject: Re: [OpenID] OpenID + Government<br> To: Paul Madsen <<mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a><mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>>><br> Cc: "<mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>><a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a><mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>>"<br> <<mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>><a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a><mailto:<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>>><br> Message-ID: <<mailto:<a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com" target="_blank">73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com</a>><a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com" target="_blank">73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com</a><mailto:<a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com" target="_blank">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 -<br> </blockquote> per<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> the model -additional extension handler names, so adding value via<br> </blockquote> the<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> extension framework. Presumably this offers something suiting<br> </blockquote> banking<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> in<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> the kdf (broken by a French student) and verisign class 1 client<br> </blockquote> certs<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> missi<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> ciphersuite, adjusts the handshake flow so missi-style key agreement<br> can share the record layer with rsa handshakes, and dod office<br> </blockquote> systems<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> get all the additional strength of missi ciphers and missi<br> </blockquote> assurances<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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<br> </blockquote> will<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> have been renamed 6 times...)<br> <br> What we want is Strong, professional security engineering, based<br> </blockquote> on cc<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> claims, STD protection profiles, evaluated cryptomodules, even<br> </blockquote> formal<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> methods proving the info flow properties of the strong type<br> </blockquote> system,...<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> And in grassroots centric openid, We want that all to be developed<br> </blockquote> in<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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" <<mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a><mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">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,<br> </blockquote> as<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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<br> </blockquote> are of<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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<br> </blockquote> meistering,<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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<br> </blockquote> of<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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<br> </blockquote> feel<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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<br> </blockquote> good<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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" <<mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a><mailto:<a href="mailto:paulmadsen@rogers.com" target="_blank">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> <<mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>><a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>><mailto:<mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>><a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">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:<mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a>><a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a>><br> <br> <mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a>> <a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a>><mailto:<mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a>><a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">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:<mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>>><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><mailto:<mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><br> <br> Subject: Re: [OpenID] OpenID + Government<br> <br> To: Brett McDowell<br> <br> <<mailto:<mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>>><mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><mailto:<mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><br> <br> Cc: OpenID List<br> <<mailto:<mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><a href="mailto:general@openid.net" target="_blank">general@openid.net</a><mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>>><mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><a href="mailto:general@openid.net" target="_blank">general@openid.net</a><mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><mailto:<mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><a href="mailto:general@openid.net" target="_blank">general@openid.net</a><mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><br> <br> Message-ID: <<mailto:<mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a>><a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a>><br> <br> <mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a>> <a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-" target="_blank">7911DEBA-</a><a href="mailto:C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a>><mailto:<mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a>><a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">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> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>><mailto:<mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>><a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>> <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> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>> <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> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>> <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> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> <br> <br> </blockquote> <br> <br> <br> --<br> --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> _______________________________________________<br> general mailing list<br> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>> <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> Nat Sakimura (=nat)<br> <<a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a>> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br> </blockquote> <br> _______________________________________________<br> general mailing list<br> <mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>><a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">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>><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> Nat Sakimura (=nat)<br> <<a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a>><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br> </blockquote> <br></div></div> _______________________________________________<br> general mailing list<div class="im"><br> <a href="mailto:general@lists.openid.net" target="_blank">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></blockquote> <br> _______________________________________________<br> general mailing list<div><div></div><div class="h5"><br> <a href="mailto:general@lists.openid.net" target="_blank">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> </div></blockquote></div><br></div></body></html>