Name space and prefix - OpenID Harmonization

[Nat Sakimura]

Hi

This may have come up earlier but ...

I think Wrap should have a namespace / versioning syntax.
Invariably, it will evolve, and will require version number etc. so, it seems better to me to have one from the beginning.

e.g.,

wrap_ns=http://whatever/wrap/1.0
wrap_client_id ... 

I would go further. Why is underscore '_' is used for the delimiter?
If we make it dot '.', it will improve the future compatibility with OpenID.
So, we could do something like:

openid.ns=http://whatever/wrap/1.0

openid.client_id ...

The same applies for OpenID. For an unknown reason, though OpenID has namespace so that we write:

openid.ns= http://specs.openid.net/auth/2.0

the prefix "openid" is fixed. We should be able to change it like:

wrap.ns=http://specs.openid.net/auth/2.0

Now, the third point.

Could we not try to harmonize the variable names between the two specs?

OpenID is in use widely, so it is kind of hard to change it, so I would request Wrap community to come closer.
For example, instead of 'callback', why cannot we use 'return_to'? So, the Wrap Web App Profile request 

will become like: 

wrap.ns=http://whatever/wrap/1.0

wrap.return_to=http://example.com/callback_url

wrap.client_state=opaque_string_to_maintain_state

wrap.client_id=the_client_identifier

If we do that, rewriting openid with wrap becomes much more straightforward, e.g., 

openid.ns=http://specs.openid.net/auth/2.x

openid.return_to=http://example.com/callback_url

openid.mode=checkid_setup

openid.client_id=client_identifier

openid.client_state=opaque_string_to_maintain_state

openid.claimed_id=http://example.com/alice

openid.identity=http://example.com/user/alice

openid.assoc_handle={some_assoc_handle}

where client_id and client_state is a new introduction to openid 2.x and 

openid.mode and going forward will be "additional parameters" from the 

point of view of Wrap. 

IMHO, we should try to harmonize/unite instead of fragmenting.

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

[Dick Hardt]

On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:

Hi

This may have come up earlier but ...

I think Wrap should have a namespace / versioning syntax.
Invariably, it will evolve, and will require version number etc. so, it seems better to me to have one from the beginning.

e.g.,

wrap_ns=http://whatever/wrap/1.0
wrap_client_id ... 

Versioning was discussed. I don't recall the details, but it was decided it did not add value.

I would go further. Why is underscore '_' is used for the delimiter?
If we make it dot '.', it will improve the future compatibility with OpenID.

Or OpenID could change to using '_'  :-)

So, we could do something like:

openid.ns=http://whatever/wrap/1.0

openid.client_id ...

The same applies for OpenID. For an unknown reason, though OpenID has namespace so that we write:

openid.ns= http://specs.openid.net/auth/2.0

the prefix "openid" is fixed. We should be able to change it like:

wrap.ns=http://specs.openid.net/auth/2.0

Now, the third point.

Could we not try to harmonize the variable names between the two specs?

OpenID is in use widely, so it is kind of hard to change it,

Interesting assumption. At IIW we discussed OpenID v Next that was NOT backward compatible. It would seem that there is an oppportunity to make changes to OpenID as well as OAuth WRAP.

so I would request Wrap community to come closer.

WRAP followed OAuth, which has much broader adoption from what I know than OpenID

IMHO, we should try to harmonize/unite instead of fragmenting.

Agreed, but perhaps the changes could happen in OpenID or a combination?

-- Dick

[Nat Sakimura]

On Fri, Feb 26, 2010 at 11:55 AM, Dick Hardt <dick....@gmail.com> wrote:

On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:

Hi

This may have come up earlier but ...

I think Wrap should have a namespace / versioning syntax.
Invariably, it will evolve, and will require version number etc. so, it seems better to me to have one from the beginning.

e.g.,

wrap_ns=http://whatever/wrap/1.0
wrap_client_id ... 

Versioning was discussed. I don't recall the details, but it was decided it did not add value.

I actually think it does. 

Perhaps not in the initial version, but in the future for sure. 

So, it is better to have it in the design from the beginning. 

 

I would go further. Why is underscore '_' is used for the delimiter?
If we make it dot '.', it will improve the future compatibility with OpenID.

Or OpenID could change to using '_'  :-)

If you use '_' as the namespace delimiter, then '_' should be disallowed in the parameter name, which is not the case right now. 

 

So, we could do something like:

openid.ns=http://whatever/wrap/1.0

openid.client_id ...

The same applies for OpenID. For an unknown reason, though OpenID has namespace so that we write:

openid.ns= http://specs.openid.net/auth/2.0

the prefix "openid" is fixed. We should be able to change it like:

wrap.ns=http://specs.openid.net/auth/2.0

Now, the third point.

Could we not try to harmonize the variable names between the two specs?

OpenID is in use widely, so it is kind of hard to change it,

Interesting assumption. At IIW we discussed OpenID v Next that was NOT backward compatible. It would seem that there is an oppportunity to make changes to OpenID as well as OAuth WRAP.

yes. The above also requires changes on the OpenID side, but I am seeing an opportunity to make the transition smoother. 

 

so I would request Wrap community to come closer.

WRAP followed OAuth, which has much broader adoption from what I know than OpenID

Arguably yes, but at the same time, 'wrap_' is not 'oauth_' ;-)

IMHO, we should try to harmonize/unite instead of fragmenting.

Agreed, but perhaps the changes could happen in OpenID or a combination?

Definitely in combination. 

It is good that OpenID Foundation finally can start creating WGs again. 

 

-- Dick

_______________________________________________
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

[Joseph Smarr]

FYI, one reason OAuth/WRAP use _ instead of . is that PHP (stupidly) converts all . to _ in query var names, so it's just easier not to fight that, esp when you have to compute signatures. So if we're naming any new params, I'd strongly argue for _ over . as the delimiter. Yes it's dumb, but PHP is not going away any time soon, so this is the clear pragmatic choice. js

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Nat Sakimura]

Goodness... 

Then what would be a good character for a delimiter? 

Or do we just use '_' for it and stop using '_' for the readability? 

=nat

[Nat Sakimura]

Actually, that was because PHP variables does not allow '.' to be in it ... 

[Martin Atkins]

On 03/01/2010 05:07 PM, Nat Sakimura wrote:
> Goodness...
>
> Then what would be a good character for a delimiter?
> Or do we just use '_' for it and stop using '_' for the readability?
>

As long as prefixes themselves never *contain* underscores (which seems
like a reasonable constraint to me) there's no ambiguity between the
underscore used as the delimiter and underscore used to separate words
in the remainder of the name.

my ($prefix, $local_name) = split(/_/, $key, 2);

[Martin Atkins]

On 02/25/2010 04:11 PM, Nat Sakimura wrote:
> Hi
>
> This may have come up earlier but ...
>
> I think Wrap should have a namespace / versioning syntax.
> Invariably, it will evolve, and will require version number etc. so, it
> seems better to me to have one from the beginning.
>
> e.g.,
>
> wrap_ns=http://whatever/wrap/1.0
> wrap_client_id ...
>

I think it's a mistake to try to design a versioning system until you
know what compatibility problem you're trying to solve.

It's possible that future versions of wrap will be compatible with the
current one but just add additional properties, in which case you can
detect the new version by noticing the new properties.

(For example, see OAuth 1.0a which is a superset of the existing
protocol so OAuth 1.0a clients can still communicate with OAuth 1.0
servers.)

If it does turn out that a backward-incompatible change is required,
then this could be achieved in other ways than an explicit version
number. For example, the SP could just use different endpoint URIs for
another version, or the prefix could be changed.

And even if there does actually need to be a version number, I'm not
convinced it needs to be something as verbose as a URI. Why not just
wrap_version=1.0 ?

Later in your message you refer to OpenID's extension mechanism, but as
an implementer of that I was dissatisfied by the fact that it requires
an implementation to scan through all of the request parameters to look
for the ones called something of the form openid.prefix.ns and then,
having determined what the prefixes mean, then go back and extract all
of the keys I'm interested in from the extension I want.

So with that said I'm not convinced that the OpenID extension mechanism
is a good source of inspiration for an extensibility or versioning
mechanism.

While I agree that WRAP and OpenID should harmonize I think it would be
better to do so by finding the best possible way to satisfy both use
cases rather than trying to shoe-horn a WRAP flow into the existing
OpenID request model, which IMHO has proven to be sub-optimal in
retrospect for a number of reasons.

[Luke Shepard]

+1 Martin.

Verbose namespaces and parameters have made OpenID URLs more difficult to work with than they need be.

[Allen Tom]

As a datapoint – OAuth 1.0a deliberately did not change the version string from 1.0 to 1.0a, and it was determined that the version parameter did not add any value. I can’t quite recall the reasoning behind this off the top of my head though.

Big +10000 to trying to harmonize OpenID and Oauth WRAP.
Allen

[Dick Hardt]

Perhaps we should use bit.ly or some other URL shortner in the code so that we don't have to type as much?

[David Recordon]

Fully agreed. :)

On Tue, Mar 2, 2010 at 11:12 AM, John Bradley <john.b...@wingaa.com> wrote:

+1

On 2010-03-02, at 4:12 PM, Breno de Medeiros wrote:

>> Big +10000 to trying to harmonize OpenID and Oauth WRAP.
>> Allen
>>
>

> +1

[Dan Brickley]

On Fri, Feb 26, 2010 at 1:46 AM, Martin Atkins <ma...@degeneration.co.uk> wrote:

> I think it's a mistake to try to design a versioning system until you know
> what compatibility problem you're trying to solve.

Having watched or participated in the evolution of various versioning
mechanisms around W3C over the years, I can only agree wholeheartedly
with this. In particular, data format standards and protocols have
quite different characteristics and sometimes versioning the two
aspects packaged together can cause pain.

cheers,

Dan