RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-12-03 Thread Recordon, David
Yeah, we looked at this a bit when drafting the extension originally.
There are just so many factors that go into password choice/enforcement
that describing them becomes quite difficult.  It also is possible to
describe features which actually are just red herrings.  I wish it was
simpler so something could be included. :-\

Also pulling general@ off this thread.

--David 

-Original Message-
From: Avery Glasser [mailto:[EMAIL PROTECTED] 
Sent: Saturday, December 02, 2006 8:35 PM
To: [EMAIL PROTECTED]
Cc: Recordon, David; specs@openid.net; [EMAIL PROTECTED]
Subject: RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft

Daniel,

It's not a bad idea, but it doesn't actually drive any more knowledge
about the security of the authentication. There are so many factors when
calculating the entropy and overall security of a password that I don't
think it should be included in the AQE.

Listing the password length, the criteria for the password, how long
since last password change and other factors should probably be either
part of the Attribute Exchange or the eventual convergence/alignment
with SAML AC.

- Avery


It might be useful to some RP's to know of any complexity schemes put 
on users' passwords.

How about:

password.min_length=8
password.max_length=16

the number of characters that the password is between.
password.max_length would probably be more useful as I don't see many 
RP's complaining if the OP allows for long passwords. I can see the RP 
wanting my password to be at least for characters though.

password.complexity=alphanumeric,mixed-case

a comma separated list of common restrictions to the password's format.

Some possible values: none, numeric, alpha, alphanumeric, 
lower-case, upper-case, mixed-case, non-dictionary, 
case-insensitive

none or omitting one of the facets would have the effect of allowing 
alphanumeric characters of any case + possible some special characters.

case sensitive.

What do you think?

Daniel E. Renfer
http://kronkltd.net/

On 12/1/06, Avery Glasser [EMAIL PROTECTED] wrote:
 All,

 Attached is the new XML for draft 2 of the AQE spec. It has been 
 checked into SVN as release 140.

 David, Can you convert it to HTML and repost it to the list?






 -- Avery

 ==
 Avery Glasser
 CTO
 VxV Solutions, Inc.

 + 1.415.992.7264 - office
 + 1.415.290.1400 - mobile
 + 1.415.651.9218 - fax

 329 Bryant Street, Suite 2D
 San Francisco, CA 94107

 email:  [EMAIL PROTECTED]
 i-name: =avery
 ==

 This e-mail (including any attachments), is confidential and intended

 only for the use of the addressee(s). It may contain information 
 covered by legal, professional or other privilege. If you are not an 
 addressee, please inform the sender immediately and destroy this 
 e-mail. Do not copy, forward, use or disclose this e-mail. Thank you.




--
==
Avery Glasser
VxV Solutions, Inc.

+ 1.415.992.7264 - office
+ 1.415.290.1400 - mobile
+ 1.415.651.9218 - fax

 
329 Bryant Street, Suite 2D
San Francisco, CA 94107
==

This e-mail (including any attachments), is confidential and intended
only for the use of the addressee(s). It may contain information covered
by legal, professional or other privilege. If you are not an addressee,
please inform the sender immediately and destroy this e-mail. Do not
copy, forward, use or disclose this e-mail. Thank you.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


OpenID Signed Assertions 1.0 - Draft 1

2006-12-03 Thread Dick Hardt

Hello List

Attached is a specification for using SAML to bind properties to an  
OpenID Identifier. The mechanism for refreshing the Assertion still  
needs to be worked out. Look forward to discussing this and the  
Attribute Exchange specifications at IIW with those of you there.


-- Dick


Title: Draft: OpenID Signed Assertions 1.0 - Draft 01



TOC

DraftD. Hardt
Sxip Identity
November 2006

OpenID Signed Assertions 1.0 - Draft 01

Abstract


	This document describes a SAML assertion schema extension for
	encoding third-party attested attribute value claims as
	OpenID attributes for use with the OpenID Attribute eXchange
	service.
  

Table of Contents

1.
Introduction
2.
Terminology
2.1.
Definitions and Conventions
3.
SAML Introduction
3.1.
SAML Assertions
4.
Employing SAML in OpenID
4.1.
Assertion Attributes
5.
OpenID SAML Attribute Profile
5.1.
Required Information
5.2.
SAML Attribute Naming
5.3.
Profile-Specific XML Attributes
5.4.
SAML Attribute Values
5.5.
Example
6.
Assertion Schema Extension
6.1.
Element openid:Assertion
6.1.1.
Element saml:Assertion
7.
OpenID Assertion Schema
8.
Refreshing an Assertion
9.
Example Signed SAML Assertion
10.
Security Considerations
11.
Acknowledgements
12.
References
12.1.
Normative References
12.2.
Informative References

Author's Address




TOC
1.
Introduction


	This document specifies an assertion schema extension of the
	Security Assertion Markup Language (SAML) V2.0 called 'OpenID
	Signed Assertions', for use with the OpenID [OpenID.authentication2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, OpenID Authentication 2.0 - Draft 10, August2006.) Attribute eXchange
	service [OpenID.attributeexchange1.0] (Hardt, D., OpenID Attribute Exchange 1.0 - Draft 03, November2006.).
  


	Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is
	an XML-based framework for creating and exchanging security
	information.  The SAMLv2 specification set is normatively
	defined by [OASIS.samlconformance2.0os] (Mishra, P., Philpott, R., and E. Maler, Conformance Requirements for the Security Assertion Markup Language 	  (SAML) V2.0, March2005.).
  


TOC
2.
Terminology


	The key words MUST, MUST NOT,
	REQUIRED, SHALL, SHALL
	NOT, SHOULD, SHOULD NOT,
	RECOMMENDED, MAY, and
	OPTIONAL in this document are to be interpreted as
	described in [RFC2119] (Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March1997.).
  


TOC
2.1.
Definitions and Conventions


	  [NOTE: Update terminology based on final OpenID 2.0 draft.]
	


	  In this specification, the term, or term component,
	  SAML refers to SAML V2.0 in all cases. For
	  example, the term SAML assertion implicitly
	  means SAMLv2 assertion.
	

  
	  For overall SAML terminology, see [OASIS.samlglossary2.0os] (Hodges, J., Philpott, R., and E. Maler, Glossary for the Security Assertion Markup Language 	  (SAML) V2.0, March2005.).
	


	  Conventional XML namespace prefixes are used throughout this
	  specification to stand for their respective namespaces as
	  follows, whether or not a namespace declaration is present
	  in the example:
	  

Prefix: openid

	  XML Namespace: http://openid.net/xmlns/2.0.
	

Prefix: ds

	  XML Namespace: http://www.w3.org/2000/09/xmldsig#.  This
	  namespace is defined in the XML Signature Syntax and
	  Processing specification [W3C.RECxmldsigcore20020212] (Solo, D., Eastlake, D., and J. Reagle, XML-Signature Syntax and Processing, February2002.) and its governing schema.
	

Prefix: saml

	  XML Namespace: urn:oasis:names:tc:SAML:2.0:assertion.
	  This is the SAML V2.0 assertion namespace [OASIS.samlcore2.0os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0, March2005.). 
	

		
	


TOC
3.
SAML Introduction


	SAML [OASIS.samlcore2.0os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0, March2005.) defines an
	XML-based framework for exchanging security
	assertions between entities.
  


	SAML can be employed to make and encode statements such as
	Beth has these profile attributes and her domain's
	certificate is available over there, and I'm making this
	statement, and here's who I am.
  


	A SAML assertion profile is the specification of the assertion
	schema extension in the context of a particular SAML profile.
	It is possibly further qualified by a particular
	implementation and/or deployment context.  Condensed examples
	of SAML assertion profiles are:
	


	The SAML assertion must contain at least one
	authentication statement and no other statements.  The
	relying party must be represented in the
	AudienceRestriction element.  The
	SubjectConfirmation Method must be Foo. etc.
	  


	The SAML assertion must contain at least one attribute
	statement and may contain more than one.