On 02/02/2008, McGovern, James F (HTSC, IT)
> Figured I would ask if anyone is interested in brainstorming the next
> version of OpenID and how it can be used in Enterprise B2B settings and not
> solely focusing on consumerish interactions. Some things that I would like
> to see in the next version are:
> 1. A discussion on how AuthZ can converge with OpenID
> 2. Modeling of relationships
> 3. Not allowing an OpenID to be a vector for SQL Injection and putting
> something around what it should look like

I'm not sure what there would be to say in the spec about this: SQL
injection is not party of the standard, but rather a feature of some
implementations :)

> 4. A way to indicate to the relying party what level of authentication has
> occurred such as did the OP check a password, how did it validate a user.
> Without this, there is no way that a trust model could be established in a
> credible way.

The provider authentication policy extension handles half of this
already (telling you what checking the OP did).  It does not cover the
trust issue though, so without a pre-existing trust relationship there
is no reason to believe the PAP assertions.

The trust side is something that would be interesting to see addressed
in future specs.

> 5. A way for OpenID relying parties to filter out Ops. In a business
> scenario, if I run the Sun employee store, I may only want the Sun OP to
> talk with me.

This is already possible with OpenID 2.0:
1. make the Sun OP provide an OP identifier URL that can be used to
initiate a directed identity request to authenticate any user of the
2. to authenticate, the Sun employee store would initiate an OpenID
request against the URL from (1) rather than asking the user to enter
an identity URL.

With this setup, the user need not know that they are using OpenID or
know what their identity URL is.

specs mailing list

Reply via email to