Re: Attribute Exchange pre-draft 5

[Johannes Ernst]

In a user-centric model, what's the difference? (Seriously)

On Apr 2, 2007, at 12:14, Josh Hoyt wrote:


On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:

One feature we didn't figure out yet if its benefits would be worth
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release and the ones
not supported by the OP.

What do you think?


My intuition is that a server could advertise what attributes it
supports rather than including this information in a user-specific
response. So, -0.5 on this. If it does go in, I'd say -1 on making it
REQUIRED.

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




Johannes Ernst
NetMesh Inc.





 http://netmesh.info/jernst

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

Re: Attribute Exchange pre-draft 5

[Johnny Bufu]

I have uploaded changes proposed at the beginning of this thread into  
SVN; if you're up to reading the xml source, it can be viewed here:


To summarize the open issues:

a) ax.mode vs multiple URIs

b) No useful gain for the OP to signal why a (required) attribute was  
not supplied; the RP needs to do data validation anyhow and decide  
what to do next based on the values it has received.

c) How to encode an "unavailable attribute" in a fetch response:
blank value (current)
con: overloads possible legitimate blank values for attributes
pro: unlikely an RP will be satisfied with a blank value for a  
required attribute
omitted attribute
con: RP may not be sure that the OP processed the request

Using the same reasoning as in b), I would say omitting an attribute  
in a response would be just as useful to the RP. Opinions?


Thanks,
Johnny

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

Re: Attribute Exchange pre-draft 5

[Johnny Bufu]

On 2-Apr-07, at 12:10 PM, Josh Hoyt wrote:
> On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> - Added ax.mode parameters to all messages, to unambiguously identify
>> the message types; the values are:
>> fetch_request
>> fetch_response
>> store_request
>> store_response_success
>> store_response_failure
>> This allows implementers to decouple the processing of the underlying
>> OpenID Auth message and the extension layer.
>
> What about using a different namespace URI for each message?
>
> I was thinking:
>  http://openid.net/srv/ax/1.0#fetch_request
>  http://openid.net/srv/ax/1.0#fetch_response
>  http://openid.net/srv/ax/1.0#store_request
>  ...
>
> That eliminates the need for an extra parameter, but makes the auth
> message processing unambiguous. It's also clear to human readers that
> those namespaces are related, since they are in the same document.

The need for a mode param came when, during implementation, having  
decoupled the openid auth message and the extension processing, we  
couldn't distinguish between a fetch response and a store request. So  
the identification bits would be most useful as a message field from  
this point of view.

Other arguments for the original proposal:
- is more inline with the core openid spec
- the extension section in the core spec seems to define the  
extension type URI as the identifier for an extension protocol,  
rather than individual messages within the protocol
- having multiple URIs could lead to confusion as to what OPs should  
put in XRDS files.

Unless there are strong opinions in favor of multiple URIs, I think  
we should go forward with the mode fields.

Johnny

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Sure, though I think there has also been a desire to do a bit of an
> actual rev to SREG to be more of a 1.1 version in terms of either
> explicitly supporting additional fields (such as avatar)  or allowing
> field names to be URIs themselves versus a hard-coded list of
> properties.

-1

SREG works because it's so dead simple. Attribute exchange is not much
more complicated, and it lets you specifiy field names with URIs *and*
allows you to define any attributes you see fit.

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

RE: SREG namespace URI rollback

[Recordon, David]

Sure, though I think there has also been a desire to do a bit of an
actual rev to SREG to be more of a 1.1 version in terms of either
explicitly supporting additional fields (such as avatar)  or allowing
field names to be URIs themselves versus a hard-coded list of
properties.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johnny Bufu
Sent: Monday, April 02, 2007 5:06 PM
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: SREG namespace URI rollback

After a chat with Josh, we settled our dispute by agreeing on the
following:

On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote:
> I think it would be reasonable to always use "sreg", if for no other 
> reason than for clarity, but re-using the Type URI as the namespace 
> alias instead of creating a new one does not imply that the alias must

> be "sreg" when using OpenID 2.
>
> What if I put my proposal this way:
>
> If Simple Registration is used with OpenID 1, the arguments MUST be 
> prefixed with "openid.sreg." If Simple Registration is used with 
> OpenID 2, the arguments MUST be in the namespace 
> "http://openid.net/sreg/1.0";


The first bit allows a implementation of SREG1.1/OpenID2 to be
seamlessly used in "compatibility mode" with OpenID1 messages, which
(together with the last two items in the proposal) would eliminate the
conflicts I was pointing out.


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

After a chat with Josh, we settled our dispute by agreeing on the  
following:

On 2-Apr-07, at 2:44 PM, Josh Hoyt wrote:
> I think it would be reasonable to always use "sreg", if for no other
> reason than for clarity, but re-using the Type URI as the namespace
> alias instead of creating a new one does not imply that the alias must
> be "sreg" when using OpenID 2.
>
> What if I put my proposal this way:
>
> If Simple Registration is used with OpenID 1, the arguments MUST be
> prefixed with "openid.sreg." If Simple Registration is used with
> OpenID 2, the arguments MUST be in the namespace
> "http://openid.net/sreg/1.0";


The first bit allows a implementation of SREG1.1/OpenID2 to be  
seamlessly used in "compatibility mode" with OpenID1 messages, which  
(together with the last two items in the proposal) would eliminate  
the conflicts I was pointing out.


Johnny

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

Re: Attribute Exchange pre-draft 5

[Dick Hardt]

On 2-Apr-07, at 2:41 PM, Rowan Kerr wrote:

> On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote:
>> I'm thinking about differentiating between an attribute that's not
>> available and an attribute that *is* available, but its value is "".
>> I. e. difference between a null pointer, and a pointer to an empty
>> string.
>
> That was part of why I had the idea of adding one or two extra
> response values... to know whether a user released the attribute
> (and whether it was supported by the OP).

Personally, I don't see that much value to the RP in the RP getting  
additional information that the data was available but not released,  
and unnecessary disclosure on behalf of the user.

>
> By looking at the namespace RDFs for the OP as you suggested,
> the RP should be able to decide whether the value is supported
> by the OP, then if it's blank AND supported, then the only thing
> the RP can't be sure about is whether or not the user released it.

Note that AX enables an OP to dynamically support new attributes on  
the fly -- and publishing ALL available attributes for a user would  
be a privacy problem.

>
> If the RP really needs a value, they can prompt the user for
> it after getting the AX response and it doesn't really matter
> whether the OP supports it or not. (Unless you're going to
> maybe try and Store it back to the OP later on).
>
> But prompting users twice for the same value (for lack of any
> way to know the cause of a blank value) might be an annoying
> experience.

The RP has given the OP a hint that the value is required. If the  
user has instructed their OP to NOT give the value, then the RP can  
then decide what to do, and the user will likely expect to get  
prompted again.


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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> But they are not the same -- the namespace alias can be different
> than "sreg". Are you suggesting that SREG1.1 must always use the
> "sreg" namespace alias?

They *are* the same protocol, going over different transports (that
is, embedded in different OpenID message formats). If you are sending
an OpenID 1 message, you *cannot* assume that the recipient will
support namespace aliases. If you're sending an OpenID 2 message, you
*cannot* assume that the recipient will support aliases without
defined namespaces.

I think it would be reasonable to always use "sreg", if for no other
reason than for clarity, but re-using the Type URI as the namespace
alias instead of creating a new one does not imply that the alias must
be "sreg" when using OpenID 2.

What if I put my proposal this way:

If Simple Registration is used with OpenID 1, the arguments MUST be
prefixed with "openid.sreg." If Simple Registration is used with
OpenID 2, the arguments MUST be in the namespace
"http://openid.net/sreg/1.0";

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

Re: Attribute Exchange pre-draft 5

[Rowan Kerr]

On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote:
> I'm thinking about differentiating between an attribute that's not
> available and an attribute that *is* available, but its value is "".
> I. e. difference between a null pointer, and a pointer to an empty
> string.

That was part of why I had the idea of adding one or two extra
response values... to know whether a user released the attribute
(and whether it was supported by the OP).

By looking at the namespace RDFs for the OP as you suggested,
the RP should be able to decide whether the value is supported
by the OP, then if it's blank AND supported, then the only thing
the RP can't be sure about is whether or not the user released it.

If the RP really needs a value, they can prompt the user for
it after getting the AX response and it doesn't really matter
whether the OP supports it or not. (Unless you're going to
maybe try and Store it back to the OP later on).

But prompting users twice for the same value (for lack of any
way to know the cause of a blank value) might be an annoying
experience.


-Rowan


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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote:
> > My intuition is that a server could advertise what attributes it
> > supports rather than including this information in a user-specific
> > response. So, -0.5 on this. If it does go in, I'd say -1 on making it
> > REQUIRED.
>
> I suppose that (one or more) RDF file(s) could be returned as part
> of the AX discovery.. and the RDF's would have the attributes
> that are supported by the OP.
>
> I was just concerned about prompting a user multiple times
> for the same data, but if an RP can discover the supported
> attributes before requesting them, then that should cover it.

Why would the user be prompted more than once? I see it like this:

 RP: I want attributes A, B, and C.
 OP: OK, I support A, and B, and the user wants to send A, so my
response will contain A, but not B or C
 RP: OK, now I have A. I'll have to prompt the user for B and C if I
require them.

Is it prompting for B again that you're worried about?

If so, and it's required for the RP to do its job, then I don't think
that it's avoidable. If the user didn't want to send it, and it's
required, the application will have to stop the user one way or
another, and offering the user *some* way to continue is reasonable.

I think that the "required" request parameter will take care of most
of the problem, because users will know that if they refuse to send a
value for that attribute, the relying party will have to ask them.

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
> > What about attributes whose value could reasonably be an empty string?
> > It would be reasonable to answer "don't do that," I'm just curious how
> > you expect this case to be handled.
>
> I'd say it's up to the RP to decide whether the data returned is
> valid for it's specific needs.

I'm thinking about differentiating between an attribute that's not
available and an attribute that *is* available, but its value is "".
I. e. difference between a null pointer, and a pointer to an empty
string.

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

Re: Attribute Exchange pre-draft 5

[Rowan Kerr]

On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote:

> On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> One feature we didn't figure out yet if its benefits would be worth
>> the added complexity:
>> - in a fetch response, distinguish between attributes
>> that the user didn't *want* to release and the ones
>> not supported by the OP.
>
> My intuition is that a server could advertise what attributes it
> supports rather than including this information in a user-specific
> response. So, -0.5 on this. If it does go in, I'd say -1 on making it
> REQUIRED.

I suppose that (one or more) RDF file(s) could be returned as part
of the AX discovery.. and the RDF's would have the attributes
that are supported by the OP.

I was just concerned about prompting a user multiple times
for the same data, but if an RP can discover the supported
attributes before requesting them, then that should cover it.

-Rowan

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

Re: Attribute Exchange pre-draft 5

[Rowan Kerr]

On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
>
> What about attributes whose value could reasonably be an empty string?
> It would be reasonable to answer "don't do that," I'm just curious how
> you expect this case to be handled.

I'd say it's up to the RP to decide whether the data returned is  
valid for
it's specific needs.

-Rowan

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

Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 2:08 PM, Josh Hoyt wrote:

> On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> Sorry - I may be missing something, but I still say the problem
>> remains: if a SREG1.1 party builds a message with a namespace alias
>> different than "sreg", it can confuse the other party which may be
>> expecting specifically "sreg".
>>
>> Or, put it differently, identifying SREG1.1 with the same URI as
>> SREG1.0 would require all RPs and OPs out there to add the namespace
>> alias param to their messages, since it is required in OpenID2/
>> SREG1.1 (and that's what the URI also means).
>
> OpenID 2 messages would use the namespace URI and OpenID 1 messages
> would use the "sreg" prefix. If you do both, all the time, you don't
> have to care which kind of message it is, but I'm not proposing that
> we require doing that.

I agree there is no issue if all parties implement both SREG1.0 and  
SREG1.1.


> If you are making a SREG request, you won't have to care whether it's
> supposed to be 1.0 or 1.1 because they're *the same*.

But they are not the same -- the namespace alias can be different  
than "sreg". Are you suggesting that SREG1.1 must always use the  
"sreg" namespace alias?

> You only have to care whether it's an OpenID 1 or OpenID 2 request  
> so that you can make
> sure that the other end understands the namespacing.

Being OpenID2 and understanding namespacing doesn't imply that the  
party also supports SREG1.1. It may only support SREG1.0, hence only  
accept "sreg" in the place of the namespace alias.


Johnny

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Sorry - I may be missing something, but I still say the problem
> remains: if a SREG1.1 party builds a message with a namespace alias
> different than "sreg", it can confuse the other party which may be
> expecting specifically "sreg".
>
> Or, put it differently, identifying SREG1.1 with the same URI as
> SREG1.0 would require all RPs and OPs out there to add the namespace
> alias param to their messages, since it is required in OpenID2/
> SREG1.1 (and that's what the URI also means).

OpenID 2 messages would use the namespace URI and OpenID 1 messages
would use the "sreg" prefix. If you do both, all the time, you don't
have to care which kind of message it is, but I'm not proposing that
we require doing that.

If you are making a SREG request, you won't have to care whether it's
supposed to be 1.0 or 1.1 because they're *the same*. You only have to
care whether it's an OpenID 1 or OpenID 2 request so that you can make
sure that the other end understands the namespacing.

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

Re: SREG namespace URI rollback

[Johnny Bufu]

On 2-Apr-07, at 1:17 PM, Josh Hoyt wrote:

> On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> I think the missing namespace in SREG1.0 can cause problems; take
>> this example:
>
> I was not proposing that we drop the namespace. Just that we don't
> introduce a new URI when the protocol is otherwise identical, and
> instead just use the existing type URI as a namespace URI.
>
> That is, an SREG 1.1 request looks like:
>
> openid.ns.s=http://openid.net/sreg/1.0&openid.s.nickname=j3h
>
> not:
>
> openid.sreg.nickname=j3h

But the OP in my example doesn't supports only SREG1.0, so it will  
send the latter. And the RP who sent the request (SREG1.1 only)  
assumed that "http://openid.net/sreg/1.0"; in the OP's XRDS meant  
SREG1.1. So even though both parties do the right thing, the  
attribute transfer doesn't happen.

> If you use "sreg" as the namespace alias, SREG 1.1 is identical to  
> SREG 1.0.
>
> Is that clearer?

Sorry - I may be missing something, but I still say the problem  
remains: if a SREG1.1 party builds a message with a namespace alias  
different than "sreg", it can confuse the other party which may be  
expecting specifically "sreg".

Or, put it differently, identifying SREG1.1 with the same URI as  
SREG1.0 would require all RPs and OPs out there to add the namespace  
alias param to their messages, since it is required in OpenID2/ 
SREG1.1 (and that's what the URI also means).


Johnny

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> I think the missing namespace in SREG1.0 can cause problems; take
> this example:

I was not proposing that we drop the namespace. Just that we don't
introduce a new URI when the protocol is otherwise identical, and
instead just use the existing type URI as a namespace URI.

That is, an SREG 1.1 request looks like:

openid.ns.s=http://openid.net/sreg/1.0&openid.s.nickname=j3h

not:

openid.sreg.nickname=j3h

If you use "sreg" as the namespace alias, SREG 1.1 is identical to SREG 1.0.

Is that clearer?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: SREG namespace URI rollback

[Johnny Bufu]

Or even:

> - RP doesn't support SREG1.0, but does support 2.0 extensions
> - RP sees in an XRDS that the OP supports SREG1.* (if the same
> namespace is used for both)
> - the OP actually only supports SREG1.0

- RP sends a SREG1.1 request, but with
openid.ns.some_alias=http://openid.net/sreg/1.0
openid.some_alias.required=...
- OP doesn't understand it

> - RP gets an SREG response without the namespace param
> - RP tries to extract SREG1.1, doesn't find a namespace and can't
> handle it
>
> So the OPs that will implement only SREG1.0 will not honor their
> statement in their XRDS files, which would require them to implement
> both versions.


Johnny

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

Re: SREG namespace URI rollback

[Johnny Bufu]

Josh,

On 2-Apr-07, at 12:43 PM, Josh Hoyt wrote:

> I'd like to change the simple registration specification so that it
> uses the type URI that is currently in use in at least PIP and
> MyOpenID as the namespace URI instead of defining a new value.
>
> As far as I can tell, the only difference between the 1.0 and 1.1
> simple registration specifications is adding the namespace URI. The
> names and meanings of all of the fields are the same, so there is no
> compatibility issue, and the URI for 1.0 is already reserved (because
> it's used as the Type URI in XRDS documents).
>
> In short, I don't think that the SREG namespace/type URI should change
> until there are incompatible changes to the simple registration
> specification.
>
> So are there any objections to rolling the URI back to
>  from
> ?


I think the missing namespace in SREG1.0 can cause problems; take  
this example:

- RP doesn't support SREG1.0, but does support 2.0 extensions
- RP sees in an XRDS that the OP supports SREG1.* (if the same  
namespace is used for both)
- the OP actually only supports SREG1.0
- RP gets an SREG response without the namespace param
- RP tries to extract SREG1.1, doesn't find a namespace and can't  
handle it

So the OPs that will implement only SREG1.0 will not honor their  
statement in their XRDS files, which would require them to implement  
both versions.


Johnny

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

SREG namespace URI rollback

[Josh Hoyt]

I'd like to change the simple registration specification so that it
uses the type URI that is currently in use in at least PIP and
MyOpenID as the namespace URI instead of defining a new value.

As far as I can tell, the only difference between the 1.0 and 1.1
simple registration specifications is adding the namespace URI. The
names and meanings of all of the fields are the same, so there is no
compatibility issue, and the URI for 1.0 is already reserved (because
it's used as the Type URI in XRDS documents).

In short, I don't think that the SREG namespace/type URI should change
until there are incompatible changes to the simple registration
specification.

So are there any objections to rolling the URI back to
 from
?

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

Re: Server-to-server channel

[Johnny Bufu]

Chris,

On 2-Apr-07, at 11:50 AM, Chris Drake wrote:

> I've also noticed a lot of discussion about attributes, which begs the
> question about how to handle things that change (eg: If I've given out
> my email address to a dozen web sites, and then I change it, how does
> my OpenID server propagate that change to all those sites?)
>
> "User Centric" implies that sites don't store anything about me, and
> that whenever they need to know stuff (eg: my email), they instead ask
> my OpenID server, which returns them the answer (unless I've since
> revoked permission or whatever).  Again - server-to-server (although
> this time in the reverse direction) applies here.

I'm not sure I fully agree on you reasoning above (about sites not  
storing anything about me).

OpenID Attribute Exchange deals with the attribute updates - see the  
"update_url" parameter in fetch requests [1].

The flow would be:

- RP informs the OP where the RP can be updated of changes in  
attribute values
- user changes the value of an attribute
- OP prompts the user with the list of RP who 'registered' for change  
notifications for that attribute
- if the user approves, the OP pushes the new values to the selected  
RPs.

This is basically a push approach, as opposed to the pull approach  
you were suggesting.

The pull approach would add (unneeded) complexity with authorization  
management. Also I don't see how the user-centricity could be  
enforced -- the user / OP can't restrict RPs from storing the data  
they need, once the data is released.


Is there a use case / feature that can be accomplished with the pull  
model, that cannot fit within what I've described above / current AX  
draft?


Johnny


[1] http://openid.net/specs/openid-attribute- 
exchange-1_0-04.html#fetch_request

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Clarified that a fetch response parameter MUST be sent for each
> requested attribute, with an empty value if the user did not supply one.
> along the lines of the above, so that the RP can fallback to
> alternative data collection methods

What about attributes whose value could reasonably be an empty string?
It would be reasonable to answer "don't do that," I'm just curious how
you expect this case to be handled.

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

Spec suggestion: Appendix A.4. HTML Identifier Markup: livejournal replacement

[Chris Drake]

Hi,

I'd like to see the "livejournal" examples replaced with ones from
somewhere that actually supports 2.0 and XRI's - it's very confusing
to pop over to livejournal and find that nothing works properly...

Kind Regards,
Chris Drake


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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> One feature we didn't figure out yet if its benefits would be worth
> the added complexity:
> - in a fetch response, distinguish between attributes
> that the user didn't *want* to release and the ones
> not supported by the OP.
>
> What do you think?

My intuition is that a server could advertise what attributes it
supports rather than including this information in a user-specific
response. So, -0.5 on this. If it does go in, I'd say -1 on making it
REQUIRED.

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Added ax.mode parameters to all messages, to unambiguously identify
> the message types; the values are:
> fetch_request
> fetch_response
> store_request
> store_response_success
> store_response_failure
> This allows implementers to decouple the processing of the underlying
> OpenID Auth message and the extension layer.

What about using a different namespace URI for each message?

I was thinking:
  http://openid.net/srv/ax/1.0#fetch_request
  http://openid.net/srv/ax/1.0#fetch_response
  http://openid.net/srv/ax/1.0#store_request
  ...

That eliminates the need for an extra parameter, but makes the auth
message processing unambiguous. It's also clear to human readers that
those namespaces are related, since they are in the same document.

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

Web Access Management

[McGovern, James F \(HTSC, IT\)]

Unlike blog sites and Internet startups, many large enteprises have purchased 
Web Access Management products such as Tivoli Access Manager, Netegrity 
Siteminder, etc where authentication doesn't occur by embedding code into the 
application. Is anyone directly working with any of the vendors in this space 
to promote OpenID?


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*

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

Server-to-server channel

[Chris Drake]

Hi,

I've been away a while - is there any server-to-server mechanism built
into OpenID yet?

I've noticed folks wanting to build a "log off" facility for OpenID,
which essentially requires the users server to inform whatever places
the user has been recently to "drop" any session info.

I've also noticed a lot of discussion about attributes, which begs the
question about how to handle things that change (eg: If I've given out
my email address to a dozen web sites, and then I change it, how does
my OpenID server propagate that change to all those sites?)

"User Centric" implies that sites don't store anything about me, and
that whenever they need to know stuff (eg: my email), they instead ask
my OpenID server, which returns them the answer (unless I've since
revoked permission or whatever).  Again - server-to-server (although
this time in the reverse direction) applies here.

Many months ago, I proposed the idea of "Single Sign On" - which is
defined as letting a user access one or more web sites in some short
period of time, without that user having to type anything in (not
their password, not their username/email, not even their giant long
identity URL), and while letting that user click just once (or
preferably zero times - that is - they're auto-magically "single
signed on" as soon as they re-visit the next different
OpenID-compatible web site for the day) to "get in". server-to-server
is again required to accomplish this user-friendly functionality.

Since I've been offline, I'm confident that there have been more use
cases for server-to-server proposed by other people as well.

Is there any way for providers and consumers to identify one-anothers
endpoints yet (in the "absence" of the user's browser as a transport
mechanism), and for attributes etc to be exchanged between?

Kind Regards,
Chris Drake


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

RE: Features for Future Versions

[Chasen, Les]

I also agree with the feedback however I wanted to just pass along how I
am using authentication and authorization on a series of applications
that I am working on.  

I have a couple of applications that use standard openid authentication
using XRDS documents but they also require the user to be authorized to
use particular resources.  In most cases authorization can be
accomplished by profile data in a local database.  In my case, though,
the authorization comes from data in a third party database.   I could
have each application just write code via some API to the third party
data source but I also want to provide for this capability to be
federated to multiple trusted sources.  I am therefore taking advantage
of the service end point selection capability described in the XRI
resolution spec at
http://www.oasis-open.org/committees/download.php/17293.


contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
 
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Drummond Reed
> Sent: Monday, April 02, 2007 2:26 PM
> To: 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))'
> Cc: specs@openid.net
> Subject: RE: Features for Future Versions
> 
> James,
> 
> I agree with Dick's feedback. I don't believe OpenID, as an overall
> Internet
> identity framework, is subject to either limitation you asked about.
But
> we
> must work our way up into each of those areas of functionality.
> 
> The more you can tell us about specific functions and use cases you'd
like
> to see supported, the better we can appraise what it will take to get
> there.
> 
> =Drummond
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
> Of Dick Hardt
> Sent: Monday, April 02, 2007 8:20 AM
> To: McGovern, James F ((HTSC, IT))
> Cc: specs@openid.net
> Subject: Re: Features for Future Versions
> 
> 
> On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:
> 
> > I originally joined this list with the hopes of injecting support
> > for relationships, authorization and attestation into the
> > specification but have been somewhat disappointed. I do have the
> > following questions?
> >
> > 1. Will OpenID avoid incorporating features where identity
> > selectors such as Cardspace don't support the functionality?
> >
> > 2. Will OpenID always constrain itself to areas where traditional
> > PKI vendors have played (authentication) and avoid areas where PKI
> > can't tread (authorization)?
> 
> Hi James
> 
> Authentication and authorization are somewhat overloaded words and
> different people mean different things by them. I recall you sending
> out a link to a set of requirements you had helped create. The
> dynamics of this mailing list tend to support concise use case
> discussion rather delve into large documents. A concise use case of
> what you mean by Authorization may prove useful to guide the
> discussion and work.
> 
> -- Dick
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: Features for Future Versions

[Gabe Wachob]

Before we get into the discussions on this list (and hopefully elsewhere),
it would be great if you (and anyone else contributing) could make a clear
IPR statement about your intent with this new functionality. If you wanted
to use Microsoft's Open Specification Promise as a template, that would be
great. We don't have formal policy about IPR moving forward (and how such a
policy would be enforced...), but the more intentions are made clear earlier
on, he better it is for everyone involved. 



David Recordon and I have been pulled in 14 different directions - one of
the things we are tasked with is cleaning up the IPR around OpenID. Such a
task would have been made simpler if everyone had stated up front that their
contributions were not subject to IPR claims (or that if they were, they
would be licensed for use with OpenID, etc). Of course, without a more
formal process and IPR policy in place, such commitments to IPR openness are
not very likely to be given forth ad hoc. So this isn't a criticism, its
just a result of the way things have happened. 

-Gabe

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Drummond Reed
> Sent: Monday, April 02, 2007 11:26 AM
> To: 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))'
> Cc: specs@openid.net
> Subject: RE: Features for Future Versions
> 
> James,
> 
> I agree with Dick's feedback. I don't believe OpenID, as an overall
> Internet
> identity framework, is subject to either limitation you asked about. But
> we
> must work our way up into each of those areas of functionality.
> 
> The more you can tell us about specific functions and use cases you'd like
> to see supported, the better we can appraise what it will take to get
> there.
> 
> =Drummond
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Monday, April 02, 2007 8:20 AM
> To: McGovern, James F ((HTSC, IT))
> Cc: specs@openid.net
> Subject: Re: Features for Future Versions
> 
> 
> On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:
> 
> > I originally joined this list with the hopes of injecting support
> > for relationships, authorization and attestation into the
> > specification but have been somewhat disappointed. I do have the
> > following questions?
> >
> > 1. Will OpenID avoid incorporating features where identity
> > selectors such as Cardspace don't support the functionality?
> >
> > 2. Will OpenID always constrain itself to areas where traditional
> > PKI vendors have played (authentication) and avoid areas where PKI
> > can't tread (authorization)?
> 
> Hi James
> 
> Authentication and authorization are somewhat overloaded words and
> different people mean different things by them. I recall you sending
> out a link to a set of requirements you had helped create. The
> dynamics of this mailing list tend to support concise use case
> discussion rather delve into large documents. A concise use case of
> what you mean by Authorization may prove useful to guide the
> discussion and work.
> 
> -- Dick
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

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

RE: Features for Future Versions

[Drummond Reed]

James,

I agree with Dick's feedback. I don't believe OpenID, as an overall Internet
identity framework, is subject to either limitation you asked about. But we
must work our way up into each of those areas of functionality.

The more you can tell us about specific functions and use cases you'd like
to see supported, the better we can appraise what it will take to get there.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dick Hardt
Sent: Monday, April 02, 2007 8:20 AM
To: McGovern, James F ((HTSC, IT))
Cc: specs@openid.net
Subject: Re: Features for Future Versions


On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:

> I originally joined this list with the hopes of injecting support  
> for relationships, authorization and attestation into the  
> specification but have been somewhat disappointed. I do have the  
> following questions?
>
> 1. Will OpenID avoid incorporating features where identity  
> selectors such as Cardspace don't support the functionality?
>
> 2. Will OpenID always constrain itself to areas where traditional  
> PKI vendors have played (authentication) and avoid areas where PKI  
> can't tread (authorization)?

Hi James

Authentication and authorization are somewhat overloaded words and  
different people mean different things by them. I recall you sending  
out a link to a set of requirements you had helped create. The  
dynamics of this mailing list tend to support concise use case  
discussion rather delve into large documents. A concise use case of  
what you mean by Authorization may prove useful to guide the  
discussion and work.

-- Dick

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

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

Re: Features for Future Versions

[Dick Hardt]

On 2-Apr-07, at 8:09 AM, McGovern, James F ((HTSC, IT)) wrote:

> I originally joined this list with the hopes of injecting support  
> for relationships, authorization and attestation into the  
> specification but have been somewhat disappointed. I do have the  
> following questions?
>
> 1. Will OpenID avoid incorporating features where identity  
> selectors such as Cardspace don't support the functionality?
>
> 2. Will OpenID always constrain itself to areas where traditional  
> PKI vendors have played (authentication) and avoid areas where PKI  
> can't tread (authorization)?

Hi James

Authentication and authorization are somewhat overloaded words and  
different people mean different things by them. I recall you sending  
out a link to a set of requirements you had helped create. The  
dynamics of this mailing list tend to support concise use case  
discussion rather delve into large documents. A concise use case of  
what you mean by Authorization may prove useful to guide the  
discussion and work.

-- Dick

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

Features for Future Versions

[McGovern, James F \(HTSC, IT\)]

I originally joined this list with the hopes of injecting support for 
relationships, authorization and attestation into the specification but have 
been somewhat disappointed. I do have the following questions?

1. Will OpenID avoid incorporating features where identity selectors such as 
Cardspace don't support the functionality?

2. Will OpenID always constrain itself to areas where traditional PKI vendors 
have played (authentication) and avoid areas where PKI can't tread 
(authorization)?


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*

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