[OpenID] OpenID + Government

Thu Aug 13 17:38:04 UTC 2009

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.
=nat

On Fri, Aug 14, 2009 at 2:32 AM, David Recordon <david at sixapart.com> wrote:

> 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.
>
> (this might also be a better discussion on the specs@ list since general at isn't supposed to get into nitty gritty of the tech)
>
> --David
>
>
> On Aug 13, 2009, at 10:12 AM, John Bradley wrote:
>
>  Again eavesdropping mitigation is a good start for LoA 2.
>>
>> LoA 3 is not just signing,  it requires chaining back to the federal trust
>> bridge CA.
>> Remember this is about the US governments requirements.
>>
>> There are non-repudiation, and revocation requirements for the signature.
>>
>> Shibboleth and Infocard are currently working with the GSA on signing and
>> trust chaining issues at LoA 3.
>>
>> Hopefully the road will be smother by the time openID gets to it.
>>
>> Though I do have to ask is it still openID with RSA or ECDSA signatures?
>>
>> John B.
>>
>> On 13-Aug-09, at 9:21 AM, Peter Williams wrote:
>>
>>  Yes, but that means adding rsa to the core of openid (which means adding
>>> asymmetric public key management). It's no longer openid!
>>>
>>> For loa2, focus on the eavesdropping requirements (for both responses AND
>>> requests).
>>>
>>> For loa3, focus on the nr only, which means certs (or signed xrd playing
>>> the role of x509 format certs).
>>>
>>>
>>>
>>>
>>> On Aug 13, 2009, at 9:00 AM, "Nat Sakimura" <sakimura at gmail.com<mailto:
>>> sakimura at gmail.com>> wrote:
>>>
>>> Just to add another merit for artifact, it is very mobile client
>>> friendly.
>>> It is pretty simple to write a spec for it, and to implement it.
>>> RSA-SHA sign, we do not have to wait until 3.0.
>>> If I remember correctly, it was one of the thing to be done in 2.1
>>> timeframe.
>>>
>>> =nat
>>>
>>> On Fri, Aug 14, 2009 at 12:55 AM, Peter Williams <<mailto:
>>> pwilliams at rapattoni.com>pwilliams at rapattoni.com<mailto:
>>> pwilliams at rapattoni.com>> wrote:
>>> if saml2 satisfies the rule, at "loa=2"and "loa=3", then we don't have to
>>> do any more than SAML2 does.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> Define v2.1 as
>>> 1. the simple addition of OAEP as a new "signing" method, and
>>> 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.
>>>
>>> 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.
>>>
>>> define v2.2 as
>>> 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).
>>> 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).
>>>
>>> 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.
>>>
>>> ________________________________________
>>> From: <mailto:openid-general-bounces at lists.openid.net>
>>> openid-general-bounces at lists.openid.net<mailto:
>>> openid-general-bounces at lists.openid.net> [<mailto:
>>> openid-general-bounces at lists.openid.net>
>>> openid-general-bounces at lists.openid.net<mailto:
>>> openid-general-bounces at lists.openid.net>] On Behalf Of John Bradley
>>> [<mailto:john.bradley at wingaa.com>john.bradley at wingaa.com<mailto:
>>> john.bradley at wingaa.com>]
>>> Sent: Wednesday, August 12, 2009 10:40 PM
>>> To: Nat Sakimura
>>> Cc: <mailto:openid-general at lists.openid.net>
>>> openid-general at lists.openid.net<mailto:openid-general at lists.openid.net>
>>> Subject: Re: [OpenID] OpenID + Government
>>>
>>> Nat,
>>>
>>> Look at sec 8.1.2
>>> Eavesdropping resistance: An authentication protocol is resistant to
>>> eavesdropping attacks if an eavesdropper who records all the messages
>>> passing
>>> between a claimant and a verifier or relying party finds that it is
>>> impractical to
>>> learn the private key, secret key or password or to otherwise obtain
>>> information
>>> that would allow the eavesdropper to impersonate the claimant.
>>> Eavesdropping
>>> resistant protocols make it impractical3 for an attacker to carry out
>>> an off-line
>>> attack where he/she records an authentication protocol run then
>>> analyses it on
>>> his/her own system for an extended period, for example by systematically
>>> attempting to try every password in a large dictionary, or by brute
>>> force
>>> exhaustion.
>>>
>>> Also Table 3 on page 39 Required Protections
>>>
>>> Using AX update_url doesn't protect the authentication token.
>>> It would send a unsolicited positive assertion to the RP return_to URL
>>> with a separate token.
>>>
>>> Also 8.2.2.2.Assertions  requires that the trusted entity(OP)
>>> authenticates to the RP using a secure protocol.  As the OP is
>>> connecting to the RP in the AX case mutual TLS would be required.
>>>
>>> In AX the store message is a indirect message sorry.  It is not
>>> relevant to the LoA 2 case in any event as LoA 2 requires protection
>>> against eavesdroppers on the reply.
>>>
>>> Honestly it is better to take LoA 1 now and work on LoA 2 with proper
>>> planning and spec cycle.
>>>
>>> A lot of thought went into the decision not to hold up openID LoA 1 by
>>> trying to include LoA 2 in the same profile.
>>>
>>> We have only covered some of the issues.  Password entropy, identity
>>> proofing, liability, and other issues all come into play at LoA 2.
>>>
>>> Getting LoA 1 approved was no cake walk itself.
>>>
>>> I have probably said too much as it is.
>>>
>>> I look forward to the GSA releasing the profile then people will have
>>> something more concrete to criticize.  I will happily take the heat
>>> for that.
>>>
>>> John B.
>>>
>>> On 12-Aug-09, at 8:48 PM, Nat Sakimura wrote:
>>>
>>>  Yes. Go for Artifact Binding!
>>>> That happens to be the main road block for even writing CX.
>>>> If we had that, we could completely reuse the OpenID protocols
>>>> already spec'ed out.
>>>> Unfortunately it is not the case.
>>>>
>>>> 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???
>>>> Hope so. See <
>>>> http://www.sakimura.org/en/modules/wordpress/index.php?p=89>
>>>> http://www.sakimura.org/en/modules/wordpress/index.php?p=89
>>>> for details in Section 4, Protocol.
>>>>
>>>> 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).
>>>>
>>>> Which document are you referring to?
>>>>
>>>> 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.
>>>>
>>>> =nat
>>>>
>>>> On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros
>>>> <<mailto:breno at google.com>breno at google.com<mailto:breno at google.com>>
>>>> wrote:
>>>> Complexity could be minimally increased by defining an artifact
>>>> profile.
>>>>
>>>> Encryption using artifact profile requires no specification, comes for
>>>> free by having OP SSL endpoints.
>>>>
>>>> Artifact profile would reduce the length of URLs, currently a problem
>>>> (not all implementations seem to handle POST very well, and POST can
>>>> be annoying on mobile devices or when changing from SSL to non-SSL
>>>> context). I think it would be more beneficial on that basis than even
>>>> from a security standpoint.
>>>>
>>>> Otherwise, I agree with John's assessment.
>>>>
>>>> On Wed, Aug 12, 2009 at 1:32 PM, John
>>>> Bradley<<mailto:john.bradley at wingaa.com>john.bradley at wingaa.com<mailto:
>>>> john.bradley at wingaa.com>> wrote:
>>>>
>>>>> Kids,
>>>>> The GSA is producing a profile of standards.
>>>>> OpenID 2.0,  PAPE and AX are the only standards.
>>>>> Surprisingly SREG 1.1 is not a standard (I guess we just forgot in
>>>>>
>>>> our
>>>>
>>>>> enthusiasm for AX)
>>>>> The last thing the GSA wants (as I understand it) is to create new
>>>>>
>>>> specs and
>>>>
>>>>> impose them on the community.    This includes picking winners and
>>>>>
>>>> losers in
>>>>
>>>>> proposed extensions.
>>>>> The GSA has not said that openID can never be LoA 2+ , only that
>>>>>
>>>> given the
>>>>
>>>>> existing specs available to profile it doesn't meet the criteria
>>>>>
>>>> of SP800-63
>>>>
>>>>> for LoA 2.
>>>>> The protocol MUST prevent assertion disclosure at LoA 2.
>>>>> That is the main roadblock.
>>>>> Other protocols encrypt the assertion to the RP or use a direct SSL
>>>>> connection (artifact binding)
>>>>> It is a tradeoff that openID community needs to consider carefully,
>>>>> security can be increased to meet LoA 2 but it will be at the
>>>>>
>>>> cost of
>>>>
>>>>> increased complexity.
>>>>> It may not be a good bargain.  That however is a decision for the
>>>>>
>>>> community
>>>>
>>>>> to make and not the GSA or any other government.
>>>>> I don't believe that CX addresses this issue,  it is intended to
>>>>>
>>>> solve a
>>>>
>>>>> different trust problem.
>>>>> Nat and I have discussed this.
>>>>> If there is a extension to openID or changes to the core spec that
>>>>>
>>>> allow
>>>>
>>>>> openID to be profiled at LoA 2+ then the GSA or whoever can
>>>>>
>>>> revisit the
>>>>
>>>>> profile.
>>>>> These things are not cast in stone.
>>>>> Some of the things in the TFAP are a challenge the Shibboleth
>>>>>
>>>> community as
>>>>
>>>>> well.
>>>>> If a bank wants to send your unencrypted data through a browser as a
>>>>> redirect, good for them.
>>>>> The GSA and OMB  have to live within SP800-63,  and given that I
>>>>>
>>>> think the
>>>>
>>>>> decision to profile openID for LoA 1 while the community sort out
>>>>>
>>>> where it
>>>>
>>>>> wants to go is reasonable.
>>>>> My opinions are my own as always, and not representative of any
>>>>>
>>>> government
>>>>
>>>>> or organization.
>>>>> Take a deep breath,  relax it is all good.
>>>>> John B.
>>>>>
>>>>> Message: 5
>>>>> Date: Wed, 12 Aug 2009 12:25:45 -0700
>>>>> From: Peter Williams <<mailto:pwilliams at rapattoni.com>
>>>>> pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
>>>>> Subject: Re: [OpenID] OpenID + Government
>>>>> To: Paul Madsen <<mailto:paulmadsen at rogers.com>paulmadsen at rogers.com
>>>>> <mailto:paulmadsen at rogers.com>>
>>>>> Cc: "<mailto:openid-general at lists.openid.net>
>>>>> openid-general at lists.openid.net<mailto:openid-general at lists.openid.net
>>>>> >"
>>>>> <<mailto:openid-general at lists.openid.net>
>>>>> openid-general at lists.openid.net<mailto:openid-general at lists.openid.net
>>>>> >>
>>>>> Message-ID: <<mailto:
>>>>> 73608B74-40FB-419E-A4A5-94C8F0C9673B at rapattoni.com>
>>>>> 73608B74-40FB-419E-A4A5-94C8F0C9673B at rapattoni.com<mailto:
>>>>> 73608B74-40FB-419E-A4A5-94C8F0C9673B at rapattoni.com>>
>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>
>>>>> Ok!
>>>>>
>>>>> So you did what myspace did: took the defined extension points and
>>>>> added value . They discarded the dh handshake, and use a vendor
>>>>> specific association protocol (apparently). Better strength and
>>>>> assurance hopefully... falling back to default (low) assurance ...
>>>>> when no better option can be found.
>>>>>
>>>>> In your case, I'll guess in the endpoint xrd that you advertise -
>>>>>
>>>> per
>>>>
>>>>> the model -additional extension handler names, so adding value via
>>>>>
>>>> the
>>>>
>>>>> extension framework. Presumably this offers something suiting
>>>>>
>>>> banking
>>>>
>>>>> frauds to only those endpoints wanting to rely on xri resolution ...
>>>>> for capability negotiation and address selection (which is the more
>>>>> openid way of doing things).
>>>>>
>>>>> This is all just like ssl, now, where folks up negotiate higher
>>>>> strength mechanisms and higher level operational assurances.
>>>>>
>>>>> But look at the difference In my tone and characterization, when
>>>>> discussing the assurance space.
>>>>>
>>>>> Let's tell the ssl story using a divisive characterization of
>>>>> assurances, now:
>>>>>
>>>>> Oh my god, netscapes 40bit rc4 ciphersuite with crappy pertabators
>>>>>
>>>> in
>>>>
>>>>> the kdf (broken by a French student) and verisign class 1 client
>>>>>
>>>> certs
>>>>
>>>>> means ALL of ssl3 is low assurance. Look! GSA confirms it. It's a
>>>>> fact! Folks must now switch to IPsec, for >loa1 assurance level when
>>>>> tunelling!
>>>>>
>>>>> No. Thats not how it was handled. Nsa/Dod comes along, puts in a
>>>>>
>>>> missi
>>>>
>>>>> ciphersuite, adjusts the handshake flow so missi-style key agreement
>>>>> can share the record layer with rsa handshakes, and dod office
>>>>>
>>>> systems
>>>>
>>>>> get all the additional strength of missi ciphers and missi
>>>>>
>>>> assurances
>>>>
>>>>> when talking amongst themselves (now featuring monthly changing user
>>>>> keying material, key comprise handling, flash authority removal,
>>>>> remote cac applet provisioning on gp smartcards...). They can still
>>>>> interwork with public sites using rsa, at low assurance, however.
>>>>>
>>>>> (I'm showing my out of dateness In federal systems. By now, missi
>>>>>
>>>> will
>>>>
>>>>> have been renamed 6 times...)
>>>>>
>>>>> What we want is Strong, professional security engineering, based
>>>>>
>>>> on cc
>>>>
>>>>> claims, STD protection profiles, evaluated cryptomodules, even
>>>>>
>>>> formal
>>>>
>>>>> methods proving the info flow properties of the strong type
>>>>>
>>>> system,...
>>>>
>>>>> And in grassroots centric openid, We want that all to be developed
>>>>>
>>>> in
>>>>
>>>>> and shown by common or garden programmers, not just defense
>>>>> contractors working for GSA-affiliated .gov sites
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Aug 12, 2009, at 8:37 AM, "Paul Madsen" <<mailto:
>>>>> paulmadsen at rogers.com>paulmadsen at rogers.com<mailto:
>>>>> paulmadsen at rogers.com>>
>>>>> wrote:
>>>>>
>>>>> As you acknowledge ('custom extension albeit'), the application you
>>>>>
>>>>> are
>>>>>
>>>>> referring to supplemented OpenID's own security in order to meet the
>>>>>
>>>>> higher assurance requirements.
>>>>>
>>>>> With the standardization of that 'custom extension' continuing to
>>>>>
>>>>> progress in the OpenID community, perhaps the GSA will in the future
>>>>>
>>>>> reevaluate whether the combination can support higher assurance?
>>>>>
>>>>> The GSA have said (or will say soon I guess) only that OpenID 2.0,
>>>>>
>>>> as
>>>>
>>>>>
>>>>> profiled, tops out at LOA1 (for US Gov RPs). The profile doeesnt
>>>>>
>>>>> mention
>>>>>
>>>>> (I think at least, I havent read it) CX or any other extensions that
>>>>>
>>>>> might supplement assurance.
>>>>>
>>>>> paul
>>>>>
>>>>> p.s. I believe I am as suspicious of the realty industry as you
>>>>>
>>>> are of
>>>>
>>>>>
>>>>> Liberty
>>>>>
>>>>> Peter Williams wrote:
>>>>>
>>>>> So there i am in 2006 trying to let our 100k realtors use their rsa
>>>>>
>>>>> tokencodes at lots of other websites in the realty universe.
>>>>>
>>>>> Sounds simple, no?
>>>>>
>>>>> And I walk into this religion style war of words, of spin
>>>>>
>>>> meistering,
>>>>
>>>>>
>>>>> claim and counterclaim ...and a omnipresent culture of the putdown.
>>>>>
>>>>> Generally: an intense over sensitivity, in the saml camp. And it's
>>>>>
>>>>> not
>>>>>
>>>>> because realty is a hot new market for websso sales!
>>>>>
>>>>> As a lapsed security engineer, i love seeing the passion (and i also
>>>>>
>>>>> love the saml product we selected, which we use everyday at a cost
>>>>>
>>>> of
>>>>
>>>>>
>>>>> deployment now of about $2000 partner link (taking about 3 days, in
>>>>>
>>>>> most cases)). But the "edginess" I see displayed across not one but
>>>>>
>>>>> several companies is a real issue for going further with saml. I
>>>>>
>>>> feel
>>>>
>>>>>
>>>>> like I'm stepping across a precipice.
>>>>>
>>>>> And the edginess gets noticibly stronger the moment i talk about
>>>>>
>>>>> (also) using openid in our customers trust networks.
>>>>>
>>>>> Now you are a good person to challenge on the bretts topic of "GSA
>>>>>
>>>>> has
>>>>>
>>>>> declared openid as inherently unable to address more than loa1
>>>>>
>>>>> assurance requirements". A firm you associate with has been using
>>>>>
>>>>> openid (with a custom extension albeit) for banking transactions-
>>>>>
>>>>> which are not trivial transactions for which low assurance is
>>>>>
>>>>> appropriate.how can I reconcile those 2 statements?
>>>>>
>>>>> Now I feel I'm being spun to even more. Brett made, in literary
>>>>>
>>>>> analysis, a reaching for that "defining" gsa classification. And in
>>>>>
>>>>> that act of reaching underminded his case for being impartial. A
>>>>>
>>>> good
>>>>
>>>>>
>>>>> politician doesn't reach for the very classification device that
>>>>>
>>>>> devides folks. He or she enables (almost magically) a acceptable
>>>>>
>>>>> tradeoff.
>>>>>
>>>>> Is kantara going to formally disarm the samlista brigade and move
>>>>>
>>>>> forward, or have we just got a new name for the same old warhorse?
>>>>>
>>>>>
>>>>>
>>>>> Grudgingly, they acceptedn
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Aug 12, 2009, at 4:10 AM, "Paul Madsen" <<mailto:
>>>>> paulmadsen at rogers.com>paulmadsen at rogers.com<mailto:
>>>>> paulmadsen at rogers.com>>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Peter, a good theory. But you forget to mention that NORAD
>>>>>
>>>>> intentionally
>>>>>
>>>>> scrambled the fighters late to allow the planes to get to the
>>>>>
>>>>> towers.
>>>>>
>>>>> Peter Williams wrote:
>>>>>
>>>>> My value- such as it is- is as an outsider.
>>>>>
>>>>> I measured 4 sources:
>>>>>
>>>>> Sun Micro rsa conference presentation on their openid pilot;
>>>>>
>>>>> rationales for never being an rp
>>>>>
>>>>> Ping identity factors gating speed of adoption of openid2 -
>>>>>
>>>>> privileged acess
>>>>>
>>>>> Scott cantors view on openid2 generally, and saml as used in xrd;
>>>>>
>>>>> raw opinion, shared freely
>>>>>
>>>>> How the uk jisc pilot of openid framed the basis for it's total
>>>>>
>>>>> adoption failure in uk academia. Was it geared to fail?
>>>>>
>>>>> Given these 4 inputs, I simply conjectured a link (liberty). I
>>>>>
>>>>> tested my conjecture by being a bit outlandish. CoMpared to the
>>>>>
>>>>> norm (fox news and msnbc), I was MILD in the imputations. Lots of
>>>>>
>>>>> Ifs, buts, shoulds, mays....that mature heads would recognize as
>>>>>
>>>>> method.
>>>>>
>>>>> Don't get upset. It's just an experiment.
>>>>>
>>>>> Little, powerless, clueless, skilless, informationless peter throws
>>>>>
>>>>> tiny word stone at mighty million dollar liberty standards lobbying
>>>>>
>>>>> machine ...and gets "over the top" reaction.
>>>>>
>>>>> Why? Why such sensitivity?
>>>>>
>>>>>
>>>>>
>>>>> On Aug 11, 2009, at 5:29 PM, "John Bradley"
>>>>>
>>>>> <<mailto:john.bradley at wingaa.com>john.bradley at wingaa.com<mailto:
>>>>> john.bradley at wingaa.com><mailto:<mailto:john.bradley at wingaa.com>
>>>>> john.bradley at wingaa.com<mailto:john.bradley at wingaa.com>>> wrote:
>>>>>
>>>>> Peter, Brett
>>>>>
>>>>> As a member of Liberty, Kantara, ICF, and OIDF.   I can say that I
>>>>>
>>>>> have never seen any indication of Liberty plotting against openID
>>>>>
>>>>> or info-card.  (I do go to most of the secret meetings)
>>>>>
>>>>> The issue with physical access is more one of not trying to boil
>>>>>
>>>>> the ocean.
>>>>>
>>>>> There is real desire by real government RPs to use open
>>>>>
>>>>> technologies and work with commercial identity providers.  There
>>>>>
>>>>> are RPs I am working with who want this yesterday.
>>>>>
>>>>> This first step is hard enough.  Many people have been working hard
>>>>>
>>>>> for many months.
>>>>>
>>>>> One of the ways we have been able to make progress is by limiting
>>>>>
>>>>> the scope.
>>>>>
>>>>> We could have done physical access, LoA 4,  p-cards and other
>>>>>
>>>>> things.
>>>>>
>>>>> The initial program by the GSA is a start not an end to the
>>>>>
>>>>> process.
>>>>>
>>>>> There will be changes to the initial profiles and additional
>>>>>
>>>>> profiles as time and requirements permit.
>>>>>
>>>>> This first step is a scary amount of work,  give us time please.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 11-Aug-09, at 5:04 PM, <mailto:<mailto:
>>>>> openid-general-request at lists.openid.net>
>>>>> openid-general-request at lists.openid.net<mailto:
>>>>> openid-general-request at lists.openid.net>
>>>>>
>>>>> <mailto:openid-general-request at lists.openid.net>
>>>>> openid-general-request at lists.openid.net<mailto:
>>>>> openid-general-request at lists.openid.net><mailto:<mailto:
>>>>> openid-general-request at lists.openid.net>
>>>>> openid-general-request at lists.openid.net<mailto:
>>>>> openid-general-request at lists.openid.net>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Date: Tue, 11 Aug 2009 13:43:29 -0700
>>>>>
>>>>> From: Peter Williams
>>>>>
>>>>> <<mailto:<mailto:pwilliams at rapattoni.com>pwilliams at rapattoni.com
>>>>> <mailto:pwilliams at rapattoni.com>><mailto:pwilliams at rapattoni.com>
>>>>> pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com><mailto:
>>>>> <mailto:pwilliams at rapattoni.com>pwilliams at rapattoni.com<mailto:
>>>>> pwilliams at rapattoni.com>
>>>>>
>>>>> Subject: Re: [OpenID] OpenID + Government
>>>>>
>>>>> To: Brett McDowell
>>>>>
>>>>> <<mailto:<mailto:email at brettmcdowell.com>email at brettmcdowell.com
>>>>> <mailto:email at brettmcdowell.com>><mailto:email at brettmcdowell.com>
>>>>> email at brettmcdowell.com<mailto:email at brettmcdowell.com><mailto:
>>>>> <mailto:email at brettmcdowell.com>email at brettmcdowell.com<mailto:
>>>>> email at brettmcdowell.com>
>>>>>
>>>>> Cc: OpenID List
>>>>> <<mailto:<mailto:general at openid.net>general at openid.net<mailto:
>>>>> general at openid.net>><mailto:general at openid.net>general at openid.net
>>>>> <mailto:general at openid.net><mailto:<mailto:general at openid.net>
>>>>> general at openid.net<mailto:general at openid.net>
>>>>>
>>>>> Message-ID: <<mailto:<mailto:
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com>
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com<mailto:
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com>
>>>>>
>>>>> <mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com>
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com<mailto:7911DEBA-
>>>>> C04B-4CC7-8A4B-967626522E9A at rapattoni.com><mailto:<mailto:
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com>
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com<mailto:
>>>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com>
>>>>>
>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>
>>>>> If the infocard stack is technically reputable, can you explain why
>>>>>
>>>>> an
>>>>>
>>>>> accredited provider would be excluded from using it (and openid)
>>>>>
>>>>> from
>>>>>
>>>>> making assertions of physical presence?
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> general mailing list
>>>>>
>>>>> <mailto:general at lists.openid.net> general at lists.openid.net<mailto:
>>>>> general at lists.openid.net><mailto:<mailto:general at lists.openid.net>
>>>>> general at lists.openid.net<mailto:general at lists.openid.net>>
>>>>>
>>>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> general mailing list
>>>>>
>>>>> <mailto:general at lists.openid.net> general at lists.openid.net<mailto:
>>>>> general at lists.openid.net>
>>>>>
>>>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> <mailto:general at lists.openid.net> general at lists.openid.net<mailto:
>>>>> general at lists.openid.net>
>>>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>
>>>>>
>>>>> End of general Digest, Vol 36, Issue 13
>>>>> ***************************************
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> <mailto:general at lists.openid.net> general at lists.openid.net<mailto:
>>>>> general at lists.openid.net>
>>>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --Breno
>>>>
>>>> +1 (650) 214-1007 desk
>>>> +1 (408) 212-0135 (Grand Central)
>>>> MTV-41-3 : 383-A
>>>> PST (GMT-8) / PDT(GMT-7)
>>>> _______________________________________________
>>>> general mailing list
>>>> <mailto:general at lists.openid.net> general at lists.openid.net<mailto:
>>>> general at lists.openid.net>
>>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> <http://www.sakimura.org/en/> http://www.sakimura.org/en/
>>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> <mailto:general at lists.openid.net>general at lists.openid.net<mailto:
>>> general at lists.openid.net>
>>> <http://lists.openid.net/mailman/listinfo/openid-general>
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> <http://www.sakimura.org/en/>http://www.sakimura.org/en/
>>>
>>
>> _______________________________________________
>> 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
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090814/00a44266/attachment-0001.htm>