<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Full NIST LOA requirements for 'assertions' (NIST uses the term in the
inclusive sense and not specific to SAML) are laid in Section 10.3.2 of
<a class="moz-txt-link-freetext" href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf">http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf</a><br>
<br>
Focusing on Level 2, the combined assertion requirements of LOA 1 &
2 are<br>
<br>
1a) All assertions recognized within this guideline must indicate the
assurance level of the initial authentication of the Claimant to the
Verifier using the former’s long-term token(s). The assurance level
indication within the assertion may be implicit (e.g., through the
identity of the Verifier implicitly indicating the resulting assurance
level) or explicit (e.g., through an explicit field within the
assertion.)<br>
1b) it must be impractical for an Attacker to manufacture an assertion
or assertion reference that can be used to impersonate the Subscriber.
If the direct model is used, the assertion which is used must be signed
by the Verifier or integrity protected using a secret key shared by the
Verifier and Relying Party, and if the indirect model is used, the
assertion reference which is used must have a minimum of 64 bits of
entropy.<br>
1c) Assertions shall be specific to a single transaction, and, if
assertion references are used, they shall be freshly generated whenever
a new assertion is created by the Verifier. In other words, assertions
and assertion references are generated for one time use.<br>
1d) all assertions sent from the Verifier to the Relying Party must
either be signed by the Verifier, or transmitted from an authenticated
Verifier via a protected channel. In either case, a strong mechanism
must be in place which allows the Relying Party to establish a binding
between the assertion reference and its corresponding assertion, based
on integrity protected (or signed) communications with the
authenticated Verifier.<br>
1e) assertions that are consumed by a Relying Party which is not part
of the same Internet domain as the Verifier must expire within 5
minutes of their creation. Assertions used within a single Internet
domain, including assertions contained in or referenced by cookies,
however, may last as long as 12 hours.<br>
2a) assertions must specify whether the name of the Subscriber is a
verified name or a pseudonym.<br>
2b) assertions shall be protected against manufacture/modification,
capture, redirect and reuse.,<br>
2c) assertions, assertion references and any session cookies used by
the Verifier or Relying party for authentication purposes, shall be
transmitted to the Subscriber through a protected channel which is
linked to the primary authentication process in such a way that session
hijacking attacks are resisted<br>
2d) To protect assertions against manufacture, modification, and
disclosure, assertions which are sent from the Verifier to the Relying
Party, whether directly or through the Subscriber’s device, shall
either be sent via a mutually authenticated channel between the
Verifier and Relying Party, or equivalently shall be signed by the
Verifier and encrypted for the Relying Party.<br>
2e) All assertion protocols used at Level 2 and above require the use
of Approved cryptographic techniques. As such, the use of Kerberos keys
derived from user generated passwords is not permitted at Level 2 or
above.<br>
<br>
<br>
paul<br>
<br>
Brett McDowell wrote:
<blockquote
cite="mid:11513031-DC4B-4AA3-9E6E-6FD28EA32BFB@projectliberty.org"
type="cite">
<div>To (what I think is) Chris' point about changing/up-leveling the
discussion out of a "OpenID vs. SAML" or "OpenID is insecure"
sidetrack, and to (what I think is) Johannes' point about capturing the
security requirements that we can base a new work stream on... I humbly
suggest we look at the requirements our friends in the US Government
(and others) are requiring now and are confident they will continue to
require regardless of (and independent of) private sector innovation.
I'm specifically referring to their requirement to compliance to the
NIST defined levels of assurance (LOA). </div>
<div><br>
</div>
<div>If I were to peer into my crystal ball I would probably see that
most of the compelling applications that governments will open to
3rd-party credentialed citizens are likely to be set to LOA 2 or LOA 3.
How about we shift this conversation to focus on how OP's can offer
OpenID-based services to their users that achieve government recognized
compliance to LOA 2 (and soon after, LOA 3)?</div>
<div><br>
</div>
<div>Some work on this has already been *started* but not progressed
in earnest. Project Concordia has some use cases that look at this
problem space. The Identity Assurance Framework looks at how any
particular credential service can achieve LOA 1 through LOA 4. What we
don't have is any analysis of what an OP could achieve with OpenID 2.0.
Knowing this will provide a clear gap analysis of what we have vs.
what we need. We can base our deliberations on these hard facts. I can
only believe this will be more productive than... actually I don't see
any alternative to this approach if we are serious about making
progress.</div>
<div><br>
</div>
<div>Next Steps?</div>
<div><br>
</div>
<div>Since I work closely with the primary US Government agency in
charge of procurement (which is quite important to the issue of
what/which IT infrastructure Federal agencies deploy), and because they
already require our certification for all federation technology prior
to being considered by agencies for procurement (this is all SAML
and/or PKI today -- just to clear up any confusion about the usage of
SAML in eCitizen applications), and since they are working closely with
us to adopt our credential assessment framework for LOA 1-2 in the very
near future (and LOA 3-4 down the road), I would be happy to talk with
them about co-hosting a kick-off event to drill into this issue as it
relates to OpenID specifically. I assume they will be interested.
They, like I, would like to see citizens be able to use whatever
private sector credentials they "already have" to access government
applications. If those are OpenID's, then lets make sure those
OpenID's are going to be acceptable to these federal Relying Parties
(who knows, we might learn something that helps us win more RP adoption
in other markets as well).</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>
<div><br>
<div apple-content-edited="true"> <span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
<div style="">
<div>Brett McDowell | +1.413.652.1248 | <a moz-do-not-send="true"
href="http://info.brettmcdowell.com">http://info.brettmcdowell.com</a></div>
</div>
</span> </div>
<br>
<div>
<div>On Mar 12, 2009, at 9:05 PM, Peter Williams wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
<div link="blue" vlink="purple" lang="EN-US">
<div class="Section1">
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);">I’ve
been playing with dynamic SAML metadata modes recently. Instead of
reading a signed XRDS file, peers dynamically sign SAML metadata
files. A SAML metadata file is only XML, and has extensions: one of
which could include an XRD or 2 (and thus get signed XRD off the
ground). You can look at the SAML endpoints as funky XRD services, all
expressed in their own markup.<o:p></o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);">The
best thing that ever happened to SAML2 was openid – as [most of] the
SAML crowd have largely got off their ultra high horse and been forced
to match openid in simplicity and effectiveness (or be made irrelevant).<o:p></o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><span
style="font-size: 11pt; font-family: Calibri,sans-serif; color: rgb(31, 73, 125);"><o:p> </o:p></span></div>
<div
style="border-style: none none none solid; border-left: 1.5pt solid blue; padding: 0in 0in 0in 4pt;">
<div>
<div
style="border-style: solid none none; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in;">
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><b><span
style="font-size: 10pt; font-family: Tahoma,sans-serif;">From:</span></b><span
style="font-size: 10pt; font-family: Tahoma,sans-serif;"><span
class="Apple-converted-space"> </span><a moz-do-not-send="true"
href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>
[<a moz-do-not-send="true" href="mailto:general-bounces@openid.net"
style="color: blue; text-decoration: underline;">mailto:general-bounces@openid.net</a>]<span
class="Apple-converted-space"> </span><b>On Behalf Of<span
class="Apple-converted-space"> </span></b>Chris Messina<br>
<b>Sent:</b><span class="Apple-converted-space"> </span>Thursday,
March 12, 2009 3:59 PM<br>
<b>To:</b><span class="Apple-converted-space"> </span>Johannes Ernst<br>
<b>Cc:</b><span class="Apple-converted-space"> </span>OpenID List<br>
<b>Subject:</b><span class="Apple-converted-space"> </span>Re:
[OpenID] TransparencyCamp and OpenID (U)<o:p></o:p></span></div>
</div>
</div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">On
Thu, Mar 12, 2009 at 4:37 PM, Johannes Ernst <jernst+<a
moz-do-not-send="true" href="http://openid.net"
style="color: blue; text-decoration: underline;">openid.net</a>@<a
moz-do-not-send="true" href="http://netmesh.us"
style="color: blue; text-decoration: underline;">netmesh.us</a>>
wrote:<o:p></o:p></div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><br>
On Mar 12, 2009, at 9:46, Ben Laurie wrote:<o:p></o:p></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">I
agree that all of SAML is way too large a pill to swallow but<br>
there's no reason subsets that are usable cannot be defined, and,<br>
indeed, have been.<o:p></o:p></div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">I
would love it if somebody was actually starting a working group (in
Apache they would call it "incubate") that would propose all the gory
details of a "more secure" form of OpenID that still fits into the
decentralized, discovery-based OpenID architecture. Only then can we
tell what may or may not be the better approach.<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">+1.<o:p></o:p></div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">I'm
not the person to do it, simply because I don't have the background,
but I'm really no longer interested in the discussion that "OpenID
isn't good enough for high-value transactions". Tell that to the
Japanese who are already pushing payments over/with OpenID.<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">If
it's got security issues, as Johannes said, we should collect a list of
them as issues and go about finding suitable solutions, best practices
or explanations for WONTFIX-type resolutions.<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">The
reality is, people will use OpenID in all kinds of cases that we can't
be able to anticipate; SAML (again, from what I hear — being mostly
SAML ignorant) is that SAML requires sysadmins to maintain and more and
more organizations want to move away from that kind of model. <o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">HTTP
succeeds because (among many, many other reasons) you can jack up your
service to things like S3 once you realize that you're not really
saving any money as a small to mid-sized organization running a server
farm. The same thing applies to user authentication and security over
time, where it'd be nice to have a fairly straight-forward,
interoperable protocol for doing authentication. From what I've heard,
I don't question the sophistication or technological pedigree of SAML;
it's just that when I hear people say that OpenID isn't secure enough,
it's like saying we should all switch to RDF because it's
OMG-so-much-better.<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">I
don't doubt that either are, if your primary concerns in life are
centered around the problems that these technologies solve; but for
folks for whom security isn't necessarily their only responsibility,
and they no longer have an IT department or staff to manage a SAML
solution and look to OpenID as a potential answer — saying that OpenID
isn't secure enough doesn't seem to be an answer to the question "well,
then what do I use?"<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">How
do we get from where we are today to a point where OpenID really does
solve a large number of security problems — if only because it
hopefully means fewer passwords in use overall — and fewer unique
accounts to maintain? Look, let's take another look at this: it isn't
just "is OpenID by itself secure?" It's: "given how OpenID changes the
makeup of and behavior in the overall ecosystem, are we now more secure
than we were before?" In general, I think the answer is yes, though of
course good security necessitates vigilance and constant improvement.<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">To
Johannes point: are we capturing these needed improvements anywhere,
and if not, can we begin to?<o:p></o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;"><o:p> </o:p></div>
</div>
<div>
<div
style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman',serif;">Chris<br>
<br clear="all">
<br>
--<span class="Apple-converted-space"> </span><br>
Chris Messina<br>
Citizen-Participant &<br>
Open Web Advocate-at-Large<br>
<br>
<a moz-do-not-send="true" href="http://factoryjoe.com"
style="color: blue; text-decoration: underline;">factoryjoe.com</a><span
class="Apple-converted-space"> </span>#<span
class="Apple-converted-space"> </span><a moz-do-not-send="true"
href="http://diso-project.org"
style="color: blue; text-decoration: underline;">diso-project.org</a><br>
<a moz-do-not-send="true" href="http://citizenagency.com"
style="color: blue; text-decoration: underline;">citizenagency.com</a><span
class="Apple-converted-space"> </span>#<span
class="Apple-converted-space"> </span><a moz-do-not-send="true"
href="http://vidoop.com"
style="color: blue; text-decoration: underline;">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ] private<o:p></o:p></div>
</div>
</div>
</div>
_______________________________________________<br>
general mailing list<br>
<a moz-do-not-send="true" href="mailto:general@openid.net"
style="color: blue; text-decoration: underline;">general@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/general"
style="color: blue; text-decoration: underline;">http://openid.net/mailman/listinfo/general</a><br>
</div>
</span></blockquote>
</div>
<br>
</div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.11.10/1996 - Release Date: 11/03/2009 8:42 PM
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font size="-1">Paul Madsen<br>
e:paulmadsen @ ntt-at.com<br>
p:613-482-0432<br>
m:613-282-8647<br>
web:connectid.blogspot.com<br>
</font><a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
src="cid:part1.05020506.09030708@rogers.com" alt="ConnectID"
style="border: 0pt none ;"></a></div>
</body>
</html>