[OpenID] RP library authors
John Bradley
ve7jtb at ve7jtb.com
Fri Sep 11 19:10:15 UTC 2009
Peter,
Thanks for the detailed response.
I need to go through it in detail.
The profile can only profile existing specs.
We did not include XRD because it is not a OASIS spec yet. (CS coming
soon)
It is also not part of openID discovery yet.
SSL/TLSv3 MUST be used for all endpoints and discovery redirects, and
the URI of the XRDS.
This also allows for secure XRI resolution which also requires SSL/TLS
for retrieving the XRD.
I think it is a stretch to imagine a SSL VPN to each endpoint but it
is perhaps possible.
We can look at excluding that for interoperability reasons if that is
your recommendation.
2.7 on the whitelist was the most recent section added.
The white-list contains
a) display name
b) provider icon URL
c) OP endpoint URL
d) discovery URL (OP Identifier)
For ALL direct communications the RP must verify that the OP endpoint
discovered in the XRDS is in the whitelist.
2.5 states that SSL/TLS is used by the RP to positively identify the
IdP.
I think you are recommending clarifying that the RP must verify that
the authority segment of the OP endpoint matches the CN or
SubjectAltName for the IdP certificate.
While this is the expected behaviour (Anything else would be
considered broken by most people), it may be worth making explicit.
I need more time to review your other points.
Thanks
John B.
On 2009-09-11, at 2:06 PM, Peter Williams wrote:
> 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
More information about the general
mailing list