<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 92.4pt 1.0in 92.4pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText>I think the Openid community has as moment to seize, wrt SSL/TLS;
and has a decision to make. Given the power structure built into the Foundation's
Board, actually achieving anything will come down to one of the large corporate
members [openly] driving the agenda.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>We have to take stock of the fact that 1. what the openid
auth spec says about https; and 2. what the community does - are simply at
odds. That double whammy pretence at assurance combined with denial of the very
need for assurance is quite typical in a community at this point in its development.
One could call this community as being at its version of the “windows 95”
crossroads – where win95 was the last of the consumer-centric PC concepts
projecting a view of a connected world in which consumers were assumed to be “too
otherwise occupied” about ease of use to ever worry about security needs (or
deal with the GUI hassles of countermeasures).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>We also have to remember that t1994-era https was not designed
to do what openid auth needs. But, its mechanisms for namespace delegation and
control practices from that 90s DNS-centric control era CAN BE repurposed for a
discovery-based world of XRD resolution. I personally feel that https can evolve
in this area - if there is a will to do it, and given such a clear mission
statement. It can evolve to provide assurance for XRD-based discovery
protocols; and its handshake and session-based connection-management enforcing
functions can also evolve - if there more will to do that too - to provide assurances
that directly support upper layer websso state machines, including that used by
openid auth2<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I think we have the technical skills to specify and build
an additional, custom SSL record-layer protocol, in this community -- if there
is a will to do it. As the https resolver in the openid world is a server-thread,
we also have a uniquely-scoped integration opportunity – one that does
not impact browser world. Of course, the end goal is not upgrading SSL itself but
upgrading https URL resolution - so https urls (vs client certs) can properly support
a url-identifier based world, when supported by a trustworthy XRDS
infrastructure.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>If we look at the assets and their properties, we can perhaps
see that first, Https is clearly in dire need of re-imagining (it's sooo early
90s DARPA-internet in its design concept). But, it is also well suited to the
problem at hand, if we can break the DNS hegemony. Then, there is the PKI toolkit
available to https endpoints these days. It is finally complete enough to allow
a suitable of key-management based assurance mechanisms to support a discovery/locator
service (i.e. key management lifecycle handling is complete, largely unbundled now
from the 1980s X.509 conception of global directories, and clearly supports both
hierarchical and p2p management domains at large scale). But most critical of
al, we actually have the people with the SSL/https knowhow, coding capabilities
and killer-app distribution capabilities to pull it off. Openid auth would be just
the first application of such a reconceived https, addressing a web3.0 world founded
on url-based routing architected explicitly to support an entire class of
discovery-based secure interworking.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>The political questions are perhaps: <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Do we have the will to break the
IETF dogmatic mantras that SSL mechanisms are for all time fixed to OSI layer 4
boundaries; <o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Do we have the will to remove
from https the link to the DNS (which would impact the business interests of
some very large companies).<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Do we have the will to address the
fear that legacy issues are “just too hard” to overcome<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Do we have the political savvy
to address the power and influence of the [competing] SAML crowd (given their cosy
track inside-access to USG funding agencies)<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Do we have the means to overcome
our own initiative-killer: “there is just no need for the openid mission to
focus [today] the missing 20% of design work that specifically addresses [a
range of] assurance”?<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> -----Original Message-----</p>
<p class=MsoPlainText>> From: general-bounces@openid.net
[mailto:general-bounces@openid.net] On</p>
<p class=MsoPlainText>> Behalf Of Ben Laurie</p>
<p class=MsoPlainText>> Sent: Friday, March 13, 2009 10:53 AM</p>
<p class=MsoPlainText>> To: Breno de Medeiros</p>
<p class=MsoPlainText>> Cc: OpenID List</p>
<p class=MsoPlainText>> Subject: Re: [OpenID] TransparencyCamp and OpenID
(U)</p>
<p class=MsoPlainText>> </p>
<p class=MsoPlainText>> On Fri, Mar 13, 2009 at 4:28 PM, Breno de Medeiros
<breno@google.com></p>
<p class=MsoPlainText>> wrote:</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > On Fri, Mar 13, 2009 at 3:42 AM, Paul Madsen
<paulmadsen@rogers.com></p>
<p class=MsoPlainText>> wrote:</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> Full NIST LOA requirements for 'assertions'
(NIST uses the term in</p>
<p class=MsoPlainText>> the</p>
<p class=MsoPlainText>> >> inclusive sense and not specific to SAML)
are laid in Section 10.3.2</p>
<p class=MsoPlainText>> of</p>
<p class=MsoPlainText>> >>
http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-</p>
<p class=MsoPlainText>> Rev1_Dec2008.pdf</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> Focusing on Level 2, the combined assertion
requirements of LOA 1 &</p>
<p class=MsoPlainText>> 2 are</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 1a) All assertions recognized within this
guideline must indicate</p>
<p class=MsoPlainText>> the</p>
<p class=MsoPlainText>> >> assurance level of the initial
authentication of the Claimant to the</p>
<p class=MsoPlainText>> >> Verifier using the former’s long-term
token(s). The assurance level</p>
<p class=MsoPlainText>> >> indication within the assertion may be
implicit (e.g., through the</p>
<p class=MsoPlainText>> identity</p>
<p class=MsoPlainText>> >> of the Verifier implicitly indicating the
resulting assurance level)</p>
<p class=MsoPlainText>> or</p>
<p class=MsoPlainText>> >> explicit (e.g., through an explicit field
within the assertion.)</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Implicit indication could be achieved by public
documentation.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 1b) it must be impractical for an
Attacker to manufacture an</p>
<p class=MsoPlainText>> assertion or</p>
<p class=MsoPlainText>> >> assertion reference that can be used to
impersonate the Subscriber.</p>
<p class=MsoPlainText>> If the</p>
<p class=MsoPlainText>> >> direct model is used, the assertion which
is used must be signed by</p>
<p class=MsoPlainText>> the</p>
<p class=MsoPlainText>> >> Verifier or integrity protected using a
secret key shared by the</p>
<p class=MsoPlainText>> Verifier</p>
<p class=MsoPlainText>> >> and Relying Party, and if the indirect
model is used, the assertion</p>
<p class=MsoPlainText>> >> reference which is used must have a minimum
of 64 bits of entropy.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Shared secret key => implies that the OP
should not accept</p>
<p class=MsoPlainText>> negotiations over</p>
<p class=MsoPlainText>> > HTTP. Even DH does not bind the shared key to
the verifier because</p>
<p class=MsoPlainText>> there is</p>
<p class=MsoPlainText>> > no authenticity.</p>
<p class=MsoPlainText>> > Response_nonce should have at least 64 bits of
entropy.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 1c) Assertions shall be specific to a
single transaction, and, if</p>
<p class=MsoPlainText>> >> assertion references are used, they shall
be freshly generated</p>
<p class=MsoPlainText>> whenever a</p>
<p class=MsoPlainText>> >> new assertion is created by the Verifier.
In other words, assertions</p>
<p class=MsoPlainText>> and</p>
<p class=MsoPlainText>> >> assertion references are generated for one
time use.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Response_nonce, if properly implemented, would
guarantee this. Both</p>
<p class=MsoPlainText>> the RP</p>
<p class=MsoPlainText>> > and the OP (in check_authentication mode)
should verify the nonce for</p>
<p class=MsoPlainText>> > uniqueness.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 1d) all assertions sent from the Verifier
to the Relying Party must</p>
<p class=MsoPlainText>> either</p>
<p class=MsoPlainText>> >> be signed by the Verifier, or transmitted
from an authenticated</p>
<p class=MsoPlainText>> Verifier via</p>
<p class=MsoPlainText>> >> a protected channel. In either case, a
strong mechanism must be in</p>
<p class=MsoPlainText>> place</p>
<p class=MsoPlainText>> >> which allows the Relying Party to establish
a binding between the</p>
<p class=MsoPlainText>> assertion</p>
<p class=MsoPlainText>> >> reference and its corresponding assertion,
based on integrity</p>
<p class=MsoPlainText>> protected (or</p>
<p class=MsoPlainText>> >> signed) communications with the
authenticated Verifier.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Implies that OP check_authentication should be
over SSL only.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 1e) assertions that are consumed by a
Relying Party which is not</p>
<p class=MsoPlainText>> part of</p>
<p class=MsoPlainText>> >> the same Internet domain as the Verifier
must expire within 5</p>
<p class=MsoPlainText>> minutes of</p>
<p class=MsoPlainText>> >> their creation. Assertions used within a
single Internet domain,</p>
<p class=MsoPlainText>> including</p>
<p class=MsoPlainText>> >> assertions contained in or referenced by
cookies, however, may last</p>
<p class=MsoPlainText>> as long</p>
<p class=MsoPlainText>> >> as 12 hours.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > That means that the RP should reject
response_nonces older than five</p>
<p class=MsoPlainText>> > minutes. Implies some level of clock skew
adjustment that OpenID does</p>
<p class=MsoPlainText>> not</p>
<p class=MsoPlainText>> > provide.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 2a) assertions must specify whether the
name of the Subscriber is a</p>
<p class=MsoPlainText>> >> verified name or a pseudonym.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Assuming it to be a pseudonym unless otherwise
specified by</p>
<p class=MsoPlainText>> extensions would</p>
<p class=MsoPlainText>> > satisfy this.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 2b) assertions shall be protected against
manufacture/modification,</p>
<p class=MsoPlainText>> >> capture, redirect and reuse.,</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Reuse is prevented by the signature inclusion
of the return_to URL,</p>
<p class=MsoPlainText>> > op_endpoint. Signature also prevents against
modification. Protecting</p>
<p class=MsoPlainText>> > against capture could be understood as a
mandate for POST, since GET</p>
<p class=MsoPlainText>> > assertions can be compromised through the
browser history prior to</p>
<p class=MsoPlainText>> their</p>
<p class=MsoPlainText>> > expiration.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 2c) assertions, assertion references and
any session cookies used by</p>
<p class=MsoPlainText>> the</p>
<p class=MsoPlainText>> >> Verifier or Relying party for
authentication purposes, shall be</p>
<p class=MsoPlainText>> transmitted</p>
<p class=MsoPlainText>> >> to the Subscriber through a protected
channel which is linked to the</p>
<p class=MsoPlainText>> primary</p>
<p class=MsoPlainText>> >> authentication process in such a way that
session hijacking attacks</p>
<p class=MsoPlainText>> are</p>
<p class=MsoPlainText>> >> resisted</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > This is not applicable, as OpenID does not rely
on common-domain</p>
<p class=MsoPlainText>> cookies.</p>
<p class=MsoPlainText>> </p>
<p class=MsoPlainText>> It constrains implementation of the Verifier and RP,
therefore not</p>
<p class=MsoPlainText>> every OpenID implementation would qualify. So, it is
applicable.</p>
<p class=MsoPlainText>> </p>
<p class=MsoPlainText>> Plus it applies to assertions and assertion
references, too.</p>
<p class=MsoPlainText>> </p>
<p class=MsoPlainText>> Which means it requires SSL or equivalent.</p>
<p class=MsoPlainText>> </p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 2d) To protect assertions against
manufacture, modification, and</p>
<p class=MsoPlainText>> >> disclosure, assertions which are sent from
the Verifier to the</p>
<p class=MsoPlainText>> Relying</p>
<p class=MsoPlainText>> >> Party, whether directly or through the
Subscriber’s device, shall</p>
<p class=MsoPlainText>> either be</p>
<p class=MsoPlainText>> >> sent via a mutually authenticated channel
between the Verifier and</p>
<p class=MsoPlainText>> Relying</p>
<p class=MsoPlainText>> >> Party, or equivalently shall be signed by
the Verifier and encrypted</p>
<p class=MsoPlainText>> for the</p>
<p class=MsoPlainText>> >> Relying Party.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > Again, implies that check_authentication should
be performed over SSL</p>
<p class=MsoPlainText>> only.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> 2e) All assertion protocols used at Level 2
and above require the</p>
<p class=MsoPlainText>> use of</p>
<p class=MsoPlainText>> >> Approved cryptographic techniques. As such,
the use of Kerberos keys</p>
<p class=MsoPlainText>> derived</p>
<p class=MsoPlainText>> >> from user generated passwords is not
permitted at Level 2 or above.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > SSL would likely meet such standards.</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > In the surface, it would seem that OpenID could
achieve such standard</p>
<p class=MsoPlainText>> with</p>
<p class=MsoPlainText>> > minor tweaks of the protocol. However, this
perception is misleading.</p>
<p class=MsoPlainText>> The</p>
<p class=MsoPlainText>> > standards was developed for non-user-centric
systems where the IDP</p>
<p class=MsoPlainText>> has</p>
<p class=MsoPlainText>> > out-of-band mechanisms to bind identifiers to
real users. In a user-</p>
<p class=MsoPlainText>> centric</p>
<p class=MsoPlainText>> > system where users can delegate arbitrary
identifiers to the OP, one</p>
<p class=MsoPlainText>> would</p>
<p class=MsoPlainText>> > expect it to be necessary to develop an
additional set of criteria by</p>
<p class=MsoPlainText>> which</p>
<p class=MsoPlainText>> > delegation can be assured to a minimum level of
integrity protection.</p>
<p class=MsoPlainText>> Today</p>
<p class=MsoPlainText>> > delegation can be achieved reasonably easily
via phishing attacks</p>
<p class=MsoPlainText>> that may</p>
<p class=MsoPlainText>> > appear relatively benign (do not ask user to
enter password</p>
<p class=MsoPlainText>> credentials, for</p>
<p class=MsoPlainText>> > instance).</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> paul</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> Brett McDowell wrote:</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> To (what I think is) Chris' point about
changing/up-leveling the</p>
<p class=MsoPlainText>> >> discussion out of a "OpenID vs.
SAML" or "OpenID is insecure"</p>
<p class=MsoPlainText>> sidetrack, and</p>
<p class=MsoPlainText>> >> to (what I think is) Johannes' point about
capturing the security</p>
<p class=MsoPlainText>> >> requirements that we can base a new work
stream on... I humbly</p>
<p class=MsoPlainText>> suggest we</p>
<p class=MsoPlainText>> >> look at the requirements our friends in the
US Government (and</p>
<p class=MsoPlainText>> others) are</p>
<p class=MsoPlainText>> >> requiring now and are confident they will
continue to require</p>
<p class=MsoPlainText>> regardless of</p>
<p class=MsoPlainText>> >> (and independent of) private sector
innovation. I'm specifically</p>
<p class=MsoPlainText>> referring</p>
<p class=MsoPlainText>> >> to their requirement to compliance to the
NIST defined levels of</p>
<p class=MsoPlainText>> assurance</p>
<p class=MsoPlainText>> >> (LOA).</p>
<p class=MsoPlainText>> >> If I were to peer into my crystal ball I
would probably see that</p>
<p class=MsoPlainText>> most of</p>
<p class=MsoPlainText>> >> the compelling applications that
governments will open to 3rd-party</p>
<p class=MsoPlainText>> >> credentialed citizens are likely to be set
to LOA 2 or LOA 3. How</p>
<p class=MsoPlainText>> about we</p>
<p class=MsoPlainText>> >> shift this conversation to focus on how
OP's can offer OpenID-based</p>
<p class=MsoPlainText>> services</p>
<p class=MsoPlainText>> >> to their users that achieve government
recognized compliance to LOA</p>
<p class=MsoPlainText>> 2 (and</p>
<p class=MsoPlainText>> >> soon after, LOA 3)?</p>
<p class=MsoPlainText>> >> Some work on this has already been
*started* but not progressed in</p>
<p class=MsoPlainText>> >> earnest. Project Concordia has some
use cases that look at this</p>
<p class=MsoPlainText>> problem</p>
<p class=MsoPlainText>> >> space. The Identity Assurance
Framework looks at how any particular</p>
<p class=MsoPlainText>> >> credential service can achieve LOA 1
through LOA 4. What we don't</p>
<p class=MsoPlainText>> have is</p>
<p class=MsoPlainText>> >> any analysis of what an OP could achieve
with OpenID 2.0. Knowing</p>
<p class=MsoPlainText>> this will</p>
<p class=MsoPlainText>> >> provide a clear gap analysis of what we
have vs. what we need. We</p>
<p class=MsoPlainText>> can base</p>
<p class=MsoPlainText>> >> our deliberations on these hard
facts. I can only believe this will</p>
<p class=MsoPlainText>> be more</p>
<p class=MsoPlainText>> >> productive than... actually I don't see any
alternative to this</p>
<p class=MsoPlainText>> approach if</p>
<p class=MsoPlainText>> >> we are serious about making progress.</p>
<p class=MsoPlainText>> >> Next Steps?</p>
<p class=MsoPlainText>> >> Since I work closely with the primary US
Government agency in charge</p>
<p class=MsoPlainText>> of</p>
<p class=MsoPlainText>> >> procurement (which is quite important to
the issue of what/which IT</p>
<p class=MsoPlainText>> >> infrastructure Federal agencies deploy),
and because they already</p>
<p class=MsoPlainText>> require</p>
<p class=MsoPlainText>> >> our certification for all federation
technology prior to being</p>
<p class=MsoPlainText>> considered by</p>
<p class=MsoPlainText>> >> agencies for procurement (this is all SAML
and/or PKI today -- just</p>
<p class=MsoPlainText>> to</p>
<p class=MsoPlainText>> >> clear up any confusion about the usage of
SAML in eCitizen</p>
<p class=MsoPlainText>> applications),</p>
<p class=MsoPlainText>> >> and since they are working closely with us
to adopt our credential</p>
<p class=MsoPlainText>> >> assessment framework for LOA 1-2 in the
very near future (and LOA 3-</p>
<p class=MsoPlainText>> 4 down</p>
<p class=MsoPlainText>> >> the road), I would be happy to talk with
them about co-hosting a</p>
<p class=MsoPlainText>> kick-off</p>
<p class=MsoPlainText>> >> event to drill into this issue as it
relates to OpenID specifically.</p>
<p class=MsoPlainText>> I</p>
<p class=MsoPlainText>> >> assume they will be interested. They,
like I, would like to see</p>
<p class=MsoPlainText>> citizens be</p>
<p class=MsoPlainText>> >> able to use whatever private sector
credentials they "already have"</p>
<p class=MsoPlainText>> to</p>
<p class=MsoPlainText>> >> access government applications. If
those are OpenID's, then lets</p>
<p class=MsoPlainText>> make sure</p>
<p class=MsoPlainText>> >> those OpenID's are going to be acceptable
to these federal Relying</p>
<p class=MsoPlainText>> Parties</p>
<p class=MsoPlainText>> >> (who knows, we might learn something that
helps us win more RP</p>
<p class=MsoPlainText>> adoption in</p>
<p class=MsoPlainText>> >> other markets as well).</p>
<p class=MsoPlainText>> >> Thoughts?</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> Brett McDowell | +1.413.652.1248 |
http://info.brettmcdowell.com</p>
<p class=MsoPlainText>> >> On Mar 12, 2009, at 9:05 PM, Peter Williams
wrote:</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> I’ve been playing with dynamic SAML
metadata modes recently. Instead</p>
<p class=MsoPlainText>> of</p>
<p class=MsoPlainText>> >> reading a signed XRDS file, peers
dynamically sign SAML metadata</p>
<p class=MsoPlainText>> files. A</p>
<p class=MsoPlainText>> >> SAML metadata file is only XML, and has
extensions: one of which</p>
<p class=MsoPlainText>> could</p>
<p class=MsoPlainText>> >> include an XRD or 2 (and thus get signed
XRD off the ground). You</p>
<p class=MsoPlainText>> can look</p>
<p class=MsoPlainText>> >> at the SAML endpoints as funky XRD
services, all expressed in their</p>
<p class=MsoPlainText>> own</p>
<p class=MsoPlainText>> >> markup.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> The best thing that ever happened to SAML2
was openid – as [most of]</p>
<p class=MsoPlainText>> the</p>
<p class=MsoPlainText>> >> SAML crowd have largely got off their ultra
high horse and been</p>
<p class=MsoPlainText>> forced to</p>
<p class=MsoPlainText>> >> match openid in simplicity and
effectiveness (or be made</p>
<p class=MsoPlainText>> irrelevant).</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> From: general-bounces@openid.net
[mailto:general-</p>
<p class=MsoPlainText>> bounces@openid.net] On</p>
<p class=MsoPlainText>> >> Behalf Of Chris Messina</p>
<p class=MsoPlainText>> >> Sent: Thursday, March 12, 2009 3:59 PM</p>
<p class=MsoPlainText>> >> To: Johannes Ernst</p>
<p class=MsoPlainText>> >> Cc: OpenID List</p>
<p class=MsoPlainText>> >> Subject: Re: [OpenID] TransparencyCamp and
OpenID (U)</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> On Thu, Mar 12, 2009 at 4:37 PM, Johannes
Ernst</p>
<p class=MsoPlainText>> >> <jernst+openid.net@netmesh.us> wrote:</p>
<p class=MsoPlainText>> >> On Mar 12, 2009, at 9:46, Ben Laurie wrote:</p>
<p class=MsoPlainText>> >> I agree that all of SAML is way too large a
pill to swallow but</p>
<p class=MsoPlainText>> >> there's no reason subsets that are usable
cannot be defined, and,</p>
<p class=MsoPlainText>> >> indeed, have been.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> I would love it if somebody was actually
starting a working group</p>
<p class=MsoPlainText>> (in</p>
<p class=MsoPlainText>> >> Apache they would call it
"incubate") that would propose all the</p>
<p class=MsoPlainText>> gory</p>
<p class=MsoPlainText>> >> details of a "more secure" form
of OpenID that still fits into the</p>
<p class=MsoPlainText>> >> decentralized, discovery-based OpenID
architecture. Only then can we</p>
<p class=MsoPlainText>> tell</p>
<p class=MsoPlainText>> >> what may or may not be the better approach.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> +1.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> I'm not the person to do it, simply because
I don't have the</p>
<p class=MsoPlainText>> background,</p>
<p class=MsoPlainText>> >> but I'm really no longer interested in the
discussion that "OpenID</p>
<p class=MsoPlainText>> isn't</p>
<p class=MsoPlainText>> >> good enough for high-value
transactions". Tell that to the Japanese</p>
<p class=MsoPlainText>> who are</p>
<p class=MsoPlainText>> >> already pushing payments over/with OpenID.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> If it's got security issues, as Johannes
said, we should collect a</p>
<p class=MsoPlainText>> list of</p>
<p class=MsoPlainText>> >> them as issues and go about finding
suitable solutions, best</p>
<p class=MsoPlainText>> practices or</p>
<p class=MsoPlainText>> >> explanations for WONTFIX-type resolutions.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> The reality is, people will use OpenID in
all kinds of cases that we</p>
<p class=MsoPlainText>> can't</p>
<p class=MsoPlainText>> >> be able to anticipate; SAML (again, from
what I hear — being mostly</p>
<p class=MsoPlainText>> SAML</p>
<p class=MsoPlainText>> >> ignorant) is that SAML requires sysadmins
to maintain and more and</p>
<p class=MsoPlainText>> more</p>
<p class=MsoPlainText>> >> organizations want to move away from that
kind of model.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> HTTP succeeds because (among many, many
other reasons) you can jack</p>
<p class=MsoPlainText>> up</p>
<p class=MsoPlainText>> >> your service to things like S3 once you
realize that you're not</p>
<p class=MsoPlainText>> really</p>
<p class=MsoPlainText>> >> saving any money as a small to mid-sized
organization running a</p>
<p class=MsoPlainText>> server farm.</p>
<p class=MsoPlainText>> >> The same thing applies to user
authentication and security over</p>
<p class=MsoPlainText>> time, where</p>
<p class=MsoPlainText>> >> it'd be nice to have a fairly
straight-forward, interoperable</p>
<p class=MsoPlainText>> protocol for</p>
<p class=MsoPlainText>> >> doing authentication. From what I've heard,
I don't question the</p>
<p class=MsoPlainText>> >> sophistication or technological pedigree of
SAML; it's just that</p>
<p class=MsoPlainText>> when I hear</p>
<p class=MsoPlainText>> >> people say that OpenID isn't secure enough,
it's like saying we</p>
<p class=MsoPlainText>> should all</p>
<p class=MsoPlainText>> >> switch to RDF because it's
OMG-so-much-better.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> I don't doubt that either are, if your
primary concerns in life are</p>
<p class=MsoPlainText>> >> centered around the problems that these
technologies solve; but for</p>
<p class=MsoPlainText>> folks</p>
<p class=MsoPlainText>> >> for whom security isn't necessarily their
only responsibility, and</p>
<p class=MsoPlainText>> they no</p>
<p class=MsoPlainText>> >> longer have an IT department or staff to
manage a SAML solution and</p>
<p class=MsoPlainText>> look to</p>
<p class=MsoPlainText>> >> OpenID as a potential answer — saying
that OpenID isn't secure</p>
<p class=MsoPlainText>> enough</p>
<p class=MsoPlainText>> >> doesn't seem to be an answer to the
question "well, then what do I</p>
<p class=MsoPlainText>> use?"</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> How do we get from where we are today to a
point where OpenID really</p>
<p class=MsoPlainText>> does</p>
<p class=MsoPlainText>> >> solve a large number of security problems
— if only because it</p>
<p class=MsoPlainText>> hopefully</p>
<p class=MsoPlainText>> >> means fewer passwords in use overall
— and fewer unique accounts to</p>
<p class=MsoPlainText>> >> maintain? Look, let's take another look at
this: it isn't just "is</p>
<p class=MsoPlainText>> OpenID by</p>
<p class=MsoPlainText>> >> itself secure?" It's: "given how
OpenID changes the makeup of and</p>
<p class=MsoPlainText>> behavior</p>
<p class=MsoPlainText>> >> in the overall ecosystem, are we now more
secure than we were</p>
<p class=MsoPlainText>> before?" In</p>
<p class=MsoPlainText>> >> general, I think the answer is yes, though
of course good security</p>
<p class=MsoPlainText>> >> necessitates vigilance and constant
improvement.</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> To Johannes point: are we capturing these
needed improvements</p>
<p class=MsoPlainText>> anywhere,</p>
<p class=MsoPlainText>> >> and if not, can we begin to?</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> Chris</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> --</p>
<p class=MsoPlainText>> >> Chris Messina</p>
<p class=MsoPlainText>> >> Citizen-Participant &</p>
<p class=MsoPlainText>> >> Open Web Advocate-at-Large</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> factoryjoe.com # diso-project.org</p>
<p class=MsoPlainText>> >> citizenagency.com # vidoop.com</p>
<p class=MsoPlainText>> >> This email is: [ ] bloggable
[X] ask first [ ] private</p>
<p class=MsoPlainText>> >>
_______________________________________________</p>
<p class=MsoPlainText>> >> general mailing list</p>
<p class=MsoPlainText>> >> general@openid.net</p>
<p class=MsoPlainText>> >> http://openid.net/mailman/listinfo/general</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> ________________________________</p>
<p class=MsoPlainText>> >> _______________________________________________</p>
<p class=MsoPlainText>> >> general mailing list</p>
<p class=MsoPlainText>> >> general@openid.net</p>
<p class=MsoPlainText>> >> http://openid.net/mailman/listinfo/general</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> ________________________________</p>
<p class=MsoPlainText>> >> No virus found in this incoming message.</p>
<p class=MsoPlainText>> >> Checked by AVG.</p>
<p class=MsoPlainText>> >> Version: 7.5.557 / Virus Database:
270.11.10/1996 - Release Date:</p>
<p class=MsoPlainText>> >> 11/03/2009 8:42 PM</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> --</p>
<p class=MsoPlainText>> >> Paul Madsen</p>
<p class=MsoPlainText>> >> e:paulmadsen @ ntt-at.com</p>
<p class=MsoPlainText>> >> p:613-482-0432</p>
<p class=MsoPlainText>> >> m:613-282-8647</p>
<p class=MsoPlainText>> >> web:connectid.blogspot.com</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> >> _______________________________________________</p>
<p class=MsoPlainText>> >> general mailing list</p>
<p class=MsoPlainText>> >> general@openid.net</p>
<p class=MsoPlainText>> >> http://openid.net/mailman/listinfo/general</p>
<p class=MsoPlainText>> >></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > --</p>
<p class=MsoPlainText>> > --Breno</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > +1 (650) 214-1007 desk</p>
<p class=MsoPlainText>> > +1 (408) 212-0135 (Grand Central)</p>
<p class=MsoPlainText>> > MTV-41-3 : 383-A</p>
<p class=MsoPlainText>> > PST (GMT-8) / PDT(GMT-7)</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> > _______________________________________________</p>
<p class=MsoPlainText>> > general mailing list</p>
<p class=MsoPlainText>> > general@openid.net</p>
<p class=MsoPlainText>> > http://openid.net/mailman/listinfo/general</p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> ></p>
<p class=MsoPlainText>> _______________________________________________</p>
<p class=MsoPlainText>> general mailing list</p>
<p class=MsoPlainText>> general@openid.net</p>
<p class=MsoPlainText>> http://openid.net/mailman/listinfo/general</p>
</div>
</body>
</html>