[OpenID] RP library authors

Fri Sep 11 18:06:02 UTC 2009

In terms of religious-debates I've seen folks having over the last 3 years, here some comments on what I found worth noting about the scheme:-

The definitive legitimization of idp-initiated websso. No more weasel words from the SAML2 folks that there is something "inappropriate" about it.

That RPs can and should define non technical matters, outside the reach of the openid2 spec (privacy, security, activation, governance).

While "Implementation-wise, OpenID is a set of protocol specifications that facilitate portable identity", the scheme itself does not claim to provide portability.

The scheme requires SSL/TLS, not https. Other bearers are not excluded (SSLVPNs are included).

The scheme does not require use of https trust conventions - e.g. DNS-based CN-field verification. https trust signals are not part of the assurance claims.

"all end user information contained in an assertion is considered self-asserted (i.e., provided by the end user without verification)" implies that the .gov sites will view the user to have property rights in the assertion (vs the OP). Participating OPs are party to this principle. (This is a MAJOR concession, in my view, as it establishes "common practice")

Several references are made to "session reset" - which is not a term I've heard anything about in 3 years of openid general discussions... It's apparently the SAML2 forceauthn=true handling requirement, with identical semantics. Nothing required the IdP or user to participate, though.

The term "SSO" is legitimate when discussing openid. We don't have to say "identity verification", to follow the party line. Furthermore, the is no suggestion (from certain vendor marketing) that openid's SSO is somehow "less" SSO than the SSO properties derived from the SAML2 and Liberty protocols.

"Reduced SSO" legitimizes the notion that an RP can also authenticate users, without regard to what one or more IdP may have done. An RP can use a second IdP, for example. There is no notion that the IdP exclusively "controls" the user session on the RP.

There is an obligation of that "RP should take steps to verify" attributes based on sensitivity. That is... the RP may do things such as the infamous email ping.

PAPE signals are only requests.

Despite saying "During discovery and Direct Communication, the RP verifies that the IdP is an ICAM-authorized LOA 1 IdP", the scheme does not say how this is done. We can guess its PKI-controlled https endpoints whose own identity verification is tied to the DNS (but this is not stated). The spec is being disingenuous in not being clear, here.

"RPs should make a risk-based decision whether to use the information in any capacity. Legitimizes that the RP performs risk management and in THIS scheme does risk management on an individual basis (since "at LOA 1, all end user information contained in an assertion is considered self-asserted")

Concerning end-user activation, an RP account must exist but may not have credentials. But, its entirely legitimate for an RP to maintain user authentication credentials, too. This is important, especially when considered in light of the option of the RP to use multiple IDPs when authorizing a RP session, perform per-user risk management, and doing attribute verification.

Both account linking and account mapping/provisioning are equally valid. During activitation, its perfectly reasonable for an RP to be doing a BoA/SiteKey/PassMark-style analysis of the user's [machine's] own **direct** connection to the RP.

"By correlating the information it receives from the assertion, [an RP] can link the end user's credential at the IdP with an existing local account" ties to the RP account to the CREDENIAL AT THE IDP, not the PPID. (I suspect this is a schema design flaw, but who am I to assert such an opinion!)

" e that LOA 1 authentication provided by OpenID 2.0 should never be used to give an end user access to another RP application with a higher LOA requirement, even if the accounts are linked" is ambiguous. Which "if the account are linked" are being referred to? Cross-linked accounts in that one RP, one per assurance level?

The RP is required to get a (conforming) eXtensible Resource Descriptor Sequence (XRDS), not an XRD.

"RP MUST also verify that the OP Endpoint URL is trusted." The scheme does not specifyc mechanism to do this.

There is a poor-man's OCSP for revoking authorized IDPs.

The cryptanalysis of 3.2 will be fun. Breaking the association handle will allow contamination of the agency records with unauthorized PII. The countermeasures do not require any particular SSL ciphersuite be used to (help) protect the handle and derived secrets (on the wire).

"http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf
i) When this URL is present in the PAPE request, the IdP MUST only respond with a positive assertion if the IdP is an ICAM-authorized LOA 1 IdP.
ii) An IdP response indicates that the end user meets LOA 1 requirements" is incompatible that the LOA#1 assertion is always self-asserted. This rules forces the IDP **ITSELF** to implicitly make an accurate legal representation.

RP-side risk management shall appropriately focus on time-related signals analysis.

In 3.5, the RP is not required to reject an assertion containing unsigned/unverified elements (such as those attached to the response value by the user's browser as the IdP's response wanders by the user's (typically untrustworthy) communication device)

3.7 states https rules for YADIS protocol. The scheme does not mandate YADIS, however.

3.7.3.a is inappropriate.

3.8.2 obligates the RP to negotiate ciphersuites in a manner which the RP is not able to do. In SSL, the SSL server role controls the ciphersuites. Reformulate as: the RP shall drop the connection is the SSL server does not offer ... ciphersuites X Y Z.

3.8.3 links, for the first time, the assurance model to SSL server certs, of unknown assurance classes. Again, the implication is https server certs, but SSLVPN server certs are equally legit (from the formulation).

3.8.5 is inappropriate

-----Original Message-----
From: openid-general-bounces at lists.openid.net [mailto:openid-general-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Friday, September 11, 2009 8:49 AM
To: Johnny Bufu
Cc: Specs Mailing List; openid General; Michael Krelin
Subject: [OpenID] RP library authors

The GSA profile for openID is available at:

http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

Many things that are SHOULD in the openID 2.0 spec are now MUST in the
profile.

There are new PAPE URI and other modifications.

Most of the OP's supporting the profile will not be restricting it to
only Gov RP's.

Any RP may elect to use all or parts of this new profile for any
purpose they choose.

Also any OP is free to support it wether or not they are on the GSA
whitelist.

To get on the GSA white-list OP's must support the profile and be
audited against a Trust Framework.  The OIDF has information available
an applying through it's program.

There are quite a number of requirements on the RP side, that need to
be met.

The sooner these features are in libraries the sooner government
agencies can move ahead with deployments.

If there is interest we can set up a google group where developers can
get there questions on implementing the profile answered.

If I can get to IIW in Nov,  I would like to organize a session on
this for people.

There will be revisions to the profile in the future as we all gain
experience.

The people who worked on the profile tried to profile only the
existing specifications as written without inventing anything
incompatible with existing implementations.

The GSA's goal is to enable as many existing identities as possible to
have access to govenment resources without making people create new
username and password accounts at each of the thousands  of potential
RP sites.

Extra attention was taken to allow openID to be used without divulging
ANY PII to the government.
This includes the use of a Pseudonymous openID identifier to allow
sites that can take no PII or do any correlation to still use openID.

The regulation on this is quite strict.  We could not convert the ID
to a pseudonym on the RP side and adhere to the regulation.

We hope that the profile maximizes participation of OP's and RPs
alike, while not placing insurmountable burdens on developers.

RP's and OP's that don't intend to make use of the profile need to
make no changes at all.

I regret bot being able to share more of this with you sooner.  The
OIDF and the other foundations were requested not to discuss this
publicly until after the government announcements.

Regards
John Bradley

_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general