Re: [Idschemas] Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Laurie Rae]

Johnny Bufu wrote:
>
> On 6-Apr-07, at 4:09 PM, Laurie Rae wrote:
>
>> Seriously though, the issue here isn't really whether or not you and 
>> your friends will go to the rugby game,
>> it's whether or not the rugby league organizers are trying to get you 
>> to go to the rugby game at the appropriate venue.
>
> I would say the venue is not that important; getting into rugby is, 
> even on an ice rink if that's where it happens.
>
>> My point? Beyond the relatively inactive state of the ID Schemas 
>> list, and the apparent momentum on the OpenID list(s),
>> what makes schemas.openid.net (and the OpenID lists) the more 
>> appropriate "venue" for this discussion?
>
> Probably nothing;  but I do think momentum is quite important.
>
>> Or, are we just trying to get people to play rugby on an ice rink, 
>> just for the sake of putting on a game?
>
> Why not? If they can actually play it on ice for a little while, I 
> would hope they will soon realize how much better it can get on grass.

Or you could give all of the players skates and introduce everyone to 
hockey. I hear it's pretty popular in certain parts of the world. ;-)

In order for people to want to go watch a rugby game, the players should 
be provided with the proper field and gear.

Trust me, watching people slide around on an ice rink without the right
gear is not the crowd pleaser you might expect it to be.

I'm not denying the importance of momentum, just questioning if it is 
the only thing that is important.


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

Re: password-free login without SSL and OP reliance (an anti-phishing solution)

[Vinay Gupta]

Doug, I'd like to work through this approach with you in some detail  
offline. The project I'm currently working on is about biometric  
digital identity in the developing world, and one of the pieces we're  
looking at is nation-state-at-a-time deployment of an extremely  
simplified public key infrastructure.

I'm going to need to sit down with your proposal in a great deal of  
detail, reread some kerberos docs, and hopefully I'll have something  
more concrete for you next week.

Vinay

--
Vinay Gupta - Designer, Hexayurt Project - an excellent public domain  
refugee shelter system
Gizmo Project VOIP: 775-743-1851 (usually works!)  Cell:  
Iceland (+354) 869-4605
http://howtolivewiki.com/hexayurt - old http://appropedia.org/ 
Hexayurt_Project - new
Skype/Gizmo/Gtalk: hexayurt   I have a proof which unfortunately this  
signature is too short


On Apr 7, 2007, at 2:59 AM, Douglas Otis wrote:

>
> On Apr 5, 2007, at 3:49 AM, Vinay Gupta wrote:
>> On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote:
>>
>>> Although the world demands GUI, terminal interfaces already offer  
>>> a powerful set of tools for doing exactly what is needed.  Public  
>>> key cryptography reduces the overhead and security concerns  
>>> substantially.  This may also provide an alternative for rather  
>>> complex OpenID extensions that will likely over reach with  
>>> respect to security.
>>
>> The literature on both Capability Based Operating Systems and  
>> Kerberos should be considered pretty closely here. It's very easy  
>> to design systems which are subject to man in the middle attacks  
>> and replay attacks, and the semantics of security are equally  
>> important (like "what did the user just cryptographically  
>> authorize? they thought they authorized access to their name, but  
>> the request lied about what it was for...")
>>
>> Kerberos has an exquisite design for handling network  
>> authentication and should probably be considered as a template for  
>> subsequent systems. It is old and well examined, and still  
>> trusted. Perhaps it would make sense to implement Kerberos over  
>> OpenID to solve some or all of these security problems?
>
> To automate secure access between servers, kerberos provides  
> centralized access control by containing all client's secrets.   
> Shared secrets and a centralized point of failure are sizable flaws  
> for large scale deployment.  In addition, OpenID is prone to  
> downgrade attacks should acknowledgment become automated.  OpenID  
> depends upon phishing prone wet-ware to authenticate URL queries  
> and the SSL certificate of the OP.
>
> That said, OpenID overcomes administering replicate signup  
> processes, where each user and website is expected to remember user- 
> names and passwords.  The user-name/password approach is fairly  
> prone to phishing attacks, where OpenID's use of redirection  
> actually increases this vulnerability which may then affect all  
> websites that the user accesses in this manner.  In addition,  
> without an alternative means of access, users are required to  
> maintain a domain in order to delegate OPs as a means to ensure  
> continued access. This would be very important when an OP is DoS  
> attacked or when an OP goes out of service.  Otherwise, OpenID  
> remains a dangerous convenience where a user-name/password must  
> still be established as an alternative method for each account.
>
> All of these problems are overcome by adding an optional extension  
> to OpenID.
>
> For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value  
> Form Encoding" should change to something like "Keyword-Value Form  
> Encoding".  Avoid using the word "key" to mean field or label.   
> This will cause confusion.
>
> Here is a rough outline:
>
> 1) OpenID defines an OP response field openid.rsa_pub, obtained  
> from its user's profile containing a SSH2 public key.
>
> 2) The RP may retain this public key and signal the user-agent by  
> offering an OpenID key-symbol button for posting a value obtained  
> from a "openid.key-auth" URI defining a file whose content verifies  
> that the identity of the user-agent has been authenticated in the  
> process of obtaining this file.  The size of this file should be  
> less that 256 bytes.
>
> 3) The user-agent obtains the "openid.key-auth" file's content and  
> posts this as a response when the OpenID key-symbol button is  
> pressed, instead of the OpenID login button.
>
> This scheme would depend upon the same host and client key pairs as  
> used for ssh, scp, sftp, etc.  The following is a hack to allow  
> direct utilization of SCP.  The OpenID identity is converted to a  
> SHA-1 hash translated to a base64 character string prefaced with  
> OpenID.  This would require operating systems able to handle 38  
> character user names.  This hash locates a repository for where  
> keys are concatenated.  An MD5 hash of the OpenID identity further  
> defines the pat

password-free login without SSL and OP reliance (an anti-phishing solution)

[Douglas Otis]

On Apr 5, 2007, at 3:49 AM, Vinay Gupta wrote:
> On Apr 5, 2007, at 10:40 AM, Douglas Otis wrote:
>
>> Although the world demands GUI, terminal interfaces already offer  
>> a powerful set of tools for doing exactly what is needed.  Public  
>> key cryptography reduces the overhead and security concerns  
>> substantially.  This may also provide an alternative for rather  
>> complex OpenID extensions that will likely over reach with respect  
>> to security.
>
> The literature on both Capability Based Operating Systems and  
> Kerberos should be considered pretty closely here. It's very easy  
> to design systems which are subject to man in the middle attacks  
> and replay attacks, and the semantics of security are equally  
> important (like "what did the user just cryptographically  
> authorize? they thought they authorized access to their name, but  
> the request lied about what it was for...")
>
> Kerberos has an exquisite design for handling network  
> authentication and should probably be considered as a template for  
> subsequent systems. It is old and well examined, and still trusted.  
> Perhaps it would make sense to implement Kerberos over OpenID to  
> solve some or all of these security problems?

To automate secure access between servers, kerberos provides  
centralized access control by containing all client's secrets.   
Shared secrets and a centralized point of failure are sizable flaws  
for large scale deployment.  In addition, OpenID is prone to  
downgrade attacks should acknowledgment become automated.  OpenID  
depends upon phishing prone wet-ware to authenticate URL queries and  
the SSL certificate of the OP.

That said, OpenID overcomes administering replicate signup processes,  
where each user and website is expected to remember user-names and  
passwords.  The user-name/password approach is fairly prone to  
phishing attacks, where OpenID's use of redirection actually  
increases this vulnerability which may then affect all websites that  
the user accesses in this manner.  In addition, without an  
alternative means of access, users are required to maintain a domain  
in order to delegate OPs as a means to ensure continued access. This  
would be very important when an OP is DoS attacked or when an OP goes  
out of service.  Otherwise, OpenID remains a dangerous convenience  
where a user-name/password must still be established as an  
alternative method for each account.

All of these problems are overcome by adding an optional extension to  
OpenID.

For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value  
Form Encoding" should change to something like "Keyword-Value Form  
Encoding".  Avoid using the word "key" to mean field or label.  This  
will cause confusion.

Here is a rough outline:

1) OpenID defines an OP response field openid.rsa_pub, obtained from  
its user's profile containing a SSH2 public key.

2) The RP may retain this public key and signal the user-agent by  
offering an OpenID key-symbol button for posting a value obtained  
from a "openid.key-auth" URI defining a file whose content verifies  
that the identity of the user-agent has been authenticated in the  
process of obtaining this file.  The size of this file should be less  
that 256 bytes.

3) The user-agent obtains the "openid.key-auth" file's content and  
posts this as a response when the OpenID key-symbol button is  
pressed, instead of the OpenID login button.

This scheme would depend upon the same host and client key pairs as  
used for ssh, scp, sftp, etc.  The following is a hack to allow  
direct utilization of SCP.  The OpenID identity is converted to a  
SHA-1 hash translated to a base64 character string prefaced with  
OpenID.  This would require operating systems able to handle 38  
character user names.  This hash locates a repository for where keys  
are concatenated.  An MD5 hash of the OpenID identity further defines  
the path component below .openid/ for the authentication value.  As  
some point in the future, verification of host and client keys should  
be done in-band.  The location of the "openid.key-auth" should not  
change and be within the RP domain, but this is not a requirement.

When a different OpenID identity is desired to obtain access to an  
account on an RP, the user would still be able to login using the  
OpenID key access method, and then request that the account be  
associated with a different OpenID after verifying the other OpenID  
identity.  This would eliminate the need to delegate OpenID OPs for  
an orderly transition to a different identity.

This method eliminates:
  - redirection for subsequent accesses
  - man-in-the middle attacks
  - continuous dependence upon the OP
  - dedicating a domain for delegation
  - most key entry related threats
  - phishing attacks

To work with Windows, a little putty is needed :)
http://www.chiark.greenend.org.uk/%7Esgtatham/putty/

-Doug
___
specs ma

RE: PROPOSAL schema.openid.net for AX (and other extensions)

[Recordon, David]

You also could go buy idschemas.org and start there, to be migrated
later if need be.  I don't really care who owns the domain since the
wider community will hold the owner to do the right thing, though I'd
imagine donating it to Identity Commons to hold would be an easy thing
to do.

Yes, VeriSign is activly developing OpenID 2.0 code in Java
(http://code.google.com/p/joid/) and evaluating if/when we'll be
implementing Attribute Exchange alongside Simple Registration.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 06, 2007 6:07 PM
To: Recordon, David
Cc: OpenID specs list; Paul Trevithick; Mark Wahl
Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)

The work is not rooted in openid.net. We are starting there. We can
easily point those definitions somewhere else later, but we need
somewhere to start.

Given that the community that cares today is in OpenID, and the domain
the community has is openid.net, it would make sense to use that domain.
A different domain is going to have the same issues of control. I would
expect that other members of the community would have concerns if it was
rooted at say sxip.org.

Happy to have further discussions at IIW, but don't see why the work
here should wait until then. Other communities may or may not want to
take advantage of what we are doing, and it will be easier for them to
understand what we have if we have working code then just more talk
about it.

To take a step back, the people to decide this should be the people that
are doing implementations. Would you clarify David if *you* are
implementing, or just sharing your opinion?

If anyone implementing would like to do something different, then I'd
welcome additional discussion, otherwise I think we should be able to
move forward with the proposal.

-- Dick

On 6-Apr-07, at 2:03 PM, Recordon, David wrote:

> I think it is great that there is new and innovative work in what 
> you've been doing.  I would also think that it would benefit the 
> entire user-centric (and even non-user-centric) community to take 
> advantage of this work regardless of the technology.  By having it 
> rooted on openid.net, I think there will be aversion to doing so and 
> other communities will rather jump to the conclusion that the OpenID 
> community is yet again reinventing the wheel by defining common core 
> attributes.
> This is what I want to avoid.
>
> By doing this in a neutral location, not tied to a specific identity 
> technology, it removes this concern as well as does more good for the 
> entire ecosystem.  If the ID Schemas project is not the right place to

> do it, then I see no reason not to create one; I would be happy to 
> front the cost of a domain name if needed.
>
> I'd also think this would be something worth discussing at IIW when 
> the entire community comes together.  I would really like to see this 
> be something that can be used by OpenID, CardSpace, Higgins, SAML, 
> etc.
>
> --David
>
> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 06, 2007 1:07 PM
> To: Recordon, David
> Cc: OpenID specs list; Paul Trevithick; Mark Wahl
> Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)
>
> If there was something out there already, I would propose we used it.
> There is not.
>
> Just like the SAML crowd has accused the OpenID crowd of reinventing 
> an identity protocol (AKA reinventing the wheel) -- the AX proposal 
> has some unique concepts that people like Paul and Mark think are 
> quite innovative. Other schemas don't support them.
>
> I have cc'ed Paul and Mark in case they can point to some new work 
> that we can take advantage of today.
>
> Other responses inserted:
>
> On 6-Apr-07, at 11:49 AM, Recordon, David wrote:
>
>> As I've stated in the past, I have no problem with using 
>> schema.openid.net to define attributes such as the authoritative URI 
>> for an OpenID URL, i-name, etc.
>>
>> I do have a problem with using this namespace to define an attribute 
>> such as a First Name.  I do not feel that this community should be 
>> dealing with all of the issues such as First Name vs. Given Name, as 
>> that is not where the expertise is, let alone it has been done in the

>> past.  I also strongly believe that due to the number of other 
>> definitions of these attributes, either we as a community should 
>> decide to use one of them or work with a project such as ID Schemas 
>> to
>
>> create a set of URIs not tied to the OpenID project that solves both 
>> our needs and the needs of others.  I do not particularly care where 
>> this work would happen and as I've said in the past, I'd be fine with

>> someone just buying a domain to do the work to preserve the speed for

>> getting this bootstrapped while not tying it to OpenID.
>
> If really don't care, then you should not care if it is happening in 
> OpenID then.
>
>>
>> First Name:
>>  - http://schemas.xmlsoap.or

Re: PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

The work is not rooted in openid.net. We are starting there. We can  
easily point those definitions somewhere else later, but we need  
somewhere to start.

Given that the community that cares today is in OpenID, and the  
domain the community has is openid.net, it would make sense to use  
that domain. A different domain is going to have the same issues of  
control. I would expect that other members of the community would  
have concerns if it was rooted at say sxip.org.

Happy to have further discussions at IIW, but don't see why the work  
here should wait until then. Other communities may or may not want to  
take advantage of what we are doing, and it will be easier for them  
to understand what we have if we have working code then just more  
talk about it.

To take a step back, the people to decide this should be the people  
that are doing implementations. Would you clarify David if *you* are  
implementing, or just sharing your opinion?

If anyone implementing would like to do something different, then I'd  
welcome additional discussion, otherwise I think we should be able to  
move forward with the proposal.

-- Dick

On 6-Apr-07, at 2:03 PM, Recordon, David wrote:

> I think it is great that there is new and innovative work in what  
> you've
> been doing.  I would also think that it would benefit the entire
> user-centric (and even non-user-centric) community to take  
> advantage of
> this work regardless of the technology.  By having it rooted on
> openid.net, I think there will be aversion to doing so and other
> communities will rather jump to the conclusion that the OpenID  
> community
> is yet again reinventing the wheel by defining common core attributes.
> This is what I want to avoid.
>
> By doing this in a neutral location, not tied to a specific identity
> technology, it removes this concern as well as does more good for the
> entire ecosystem.  If the ID Schemas project is not the right place to
> do it, then I see no reason not to create one; I would be happy to  
> front
> the cost of a domain name if needed.
>
> I'd also think this would be something worth discussing at IIW when  
> the
> entire community comes together.  I would really like to see this be
> something that can be used by OpenID, CardSpace, Higgins, SAML, etc.
>
> --David
>
> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 06, 2007 1:07 PM
> To: Recordon, David
> Cc: OpenID specs list; Paul Trevithick; Mark Wahl
> Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)
>
> If there was something out there already, I would propose we used it.
> There is not.
>
> Just like the SAML crowd has accused the OpenID crowd of  
> reinventing an
> identity protocol (AKA reinventing the wheel) -- the AX proposal has
> some unique concepts that people like Paul and Mark think are quite
> innovative. Other schemas don't support them.
>
> I have cc'ed Paul and Mark in case they can point to some new work  
> that
> we can take advantage of today.
>
> Other responses inserted:
>
> On 6-Apr-07, at 11:49 AM, Recordon, David wrote:
>
>> As I've stated in the past, I have no problem with using
>> schema.openid.net to define attributes such as the authoritative URI
>> for an OpenID URL, i-name, etc.
>>
>> I do have a problem with using this namespace to define an attribute
>> such as a First Name.  I do not feel that this community should be
>> dealing with all of the issues such as First Name vs. Given Name, as
>> that is not where the expertise is, let alone it has been done in the
>> past.  I also strongly believe that due to the number of other
>> definitions of these attributes, either we as a community should
>> decide to use one of them or work with a project such as ID  
>> Schemas to
>
>> create a set of URIs not tied to the OpenID project that solves both
>> our needs and the needs of others.  I do not particularly care where
>> this work would happen and as I've said in the past, I'd be fine with
>> someone just buying a domain to do the work to preserve the speed for
>> getting this bootstrapped while not tying it to OpenID.
>
> If really don't care, then you should not care if it is happening in
> OpenID then.
>
>>
>> First Name:
>>  - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
>
> This URL could be used. To date they have not made these self
> describing. Who knows what this is? The AX proposal is to make the
> URLs describing. This makes it easier for programmers to know what it
> is they are working with.
>
>>  - http://xmlns.com/foaf/0.1/firstName
>>  - http://xmlns.com/foaf/0.1/givenname
>
> Both of these are elements in a larger XML document. This is not the
> model of AX.
>
>>  - http://en.wikipedia.org/wiki/First_name
>
> While intriguing to have wikiality define terms, this is not
> practical since the definition needs to be static or code will break
>
>>
>> I'm sure if Paul Trevithick or Mark Whal join this conversation  
>> th

Re: [Idschemas] Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 6-Apr-07, at 4:09 PM, Laurie Rae wrote:

> Seriously though, the issue here isn't really whether or not you  
> and your friends will go to the rugby game,
> it's whether or not the rugby league organizers are trying to get  
> you to go to the rugby game at the appropriate venue.

I would say the venue is not that important; getting into rugby is,  
even on an ice rink if that's where it happens.

> My point? Beyond the relatively inactive state of the ID Schemas  
> list, and the apparent momentum on the OpenID list(s),
> what makes schemas.openid.net (and the OpenID lists) the more  
> appropriate "venue" for this discussion?

Probably nothing;  but I do think momentum is quite important.

> Or, are we just trying to get people to play rugby on an ice rink,  
> just for the sake of putting on a game?

Why not? If they can actually play it on ice for a little while, I  
would hope they will soon realize how much better it can get on grass.


Johnny

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

Re: [Idschemas] Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Laurie Rae]

Ah, but I ask you this. If a rugby player falls in the forest, does 
anybody care? ;-)

Seriously though, the issue here isn't really whether or not you and 
your friends will go to the rugby game,
it's whether or not the rugby league organizers are trying to get you to 
go to the rugby game at the appropriate venue.

If you go watch a rugby game on an ice rink, chances are you're not 
going to get into rugby.

My point? Beyond the relatively inactive state of the ID Schemas list, 
and the apparent momentum on the OpenID list(s),
what makes schemas.openid.net (and the OpenID lists) the more 
appropriate "venue" for this discussion?

Or, are we just trying to get people to play rugby on an ice rink, just 
for the sake of putting on a game?

(then again, I am by no means a computer scientist, nor a sociologist 
for that matter)

- Laurie Rae

Johnny Bufu wrote:
> On 5-Apr-07, at 9:24 AM, Recordon, David wrote:
>   
>> I'm all about taking advantage of existing momentum, but I have a hard
>> time seeing anyone who cares about AX being unwilling to have this
>> discussion as a part of the ID Schemas community.  If there is anyone,
>> I'd certainly like to understand the reasons why (beyond it being
>> "hard").
>> 
>
> I believe a key difference here is between what people would be  
> willing to do, and what people actually (will) do. For example:
>
> - I would be willing to go to a rugby game, but I don't know if any  
> of my friends are going, so I probably won't go
> - most of my friends who like rugby may be thinking and acting the  
> same way, or
> - most of my friends would go if they knew rugby, but they haven't  
> discovered it yet.
>
>  From what I've seen, interesting discussions can be sparkled and  
> facilitated by people who do not seem to have been particularly  
> interested in a subject beforehand, but happened to be around because  
> they shared a broader interest with the community.
>
> We seem to have to potential to build momentum and a critical mass  
> for AX and schema discussions here. I propose we continue the  
> discussions wherever they happen to take place. If the intensity  
> doesn't fade out, having invested a fair bit interest people will be  
> more likely to move to a better suited place if asked to.
>
>
> (Just my thoughts, I am by no means a sociology expert.)
>
>
> Johnny
>   
> ___
> Idschemas mailing list
> [EMAIL PROTECTED]
> http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas
>
>   

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

Re: Logout

[Johannes Ernst]

On Apr 6, 2007, at 14:40, Johnny Bufu wrote:


Which makes me think that this could
actually work with what we have today, if we defined a "openid-logout-
notification" attribute, and the RPs registered for updates when its
value changes.


This sounds like you are conflating attributes of the person(a) with  
attributes of a browser session. What if I use two browsers at the  
same time, and I want to only log out from one? (because I'm leaving  
my desktop, say, and continue to work on my laptop?)


Or am I misunderstanding what you are saying?


Johannes Ernst
NetMesh Inc.





 http://netmesh.info/jernst

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

Re: Logout

[Johnny Bufu]

On 6-Apr-07, at 12:13 PM, Praveen Alavilli wrote:
> well with OpenID atleast, I think we can easily design a logout
> extension, where an RP can register it's logout handler with OP during
> login flow (checkid_immediate/checkid_setup) and the OP could call  
> each
> of the RP's logout handlers (in the browser) that are registered with
> the current session when a user logs out from the OP.

Interesting - what you're describing above looks a lot like the  
update_url feature in AX. Which makes me think that this could  
actually work with what we have today, if we defined a "openid-logout- 
notification" attribute, and the RPs registered for updates when its  
value changes.

> Ofcourse this also requires a new logout mode supported by OP,  
> which an RP can call when a
> user wants to logout from the RP itself. The OP then can provide  
> options
> to the user whether to sign out from one RP or from all.
>
> Any reason why something like this was not incorporated into the  
> specs yet ?

Not sure where this feature would be placed best.


Johnny

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 5-Apr-07, at 9:24 AM, Recordon, David wrote:
> I'm all about taking advantage of existing momentum, but I have a hard
> time seeing anyone who cares about AX being unwilling to have this
> discussion as a part of the ID Schemas community.  If there is anyone,
> I'd certainly like to understand the reasons why (beyond it being
> "hard").

I believe a key difference here is between what people would be  
willing to do, and what people actually (will) do. For example:

- I would be willing to go to a rugby game, but I don't know if any  
of my friends are going, so I probably won't go
- most of my friends who like rugby may be thinking and acting the  
same way, or
- most of my friends would go if they knew rugby, but they haven't  
discovered it yet.

 From what I've seen, interesting discussions can be sparkled and  
facilitated by people who do not seem to have been particularly  
interested in a subject beforehand, but happened to be around because  
they shared a broader interest with the community.

We seem to have to potential to build momentum and a critical mass  
for AX and schema discussions here. I propose we continue the  
discussions wherever they happen to take place. If the intensity  
doesn't fade out, having invested a fair bit interest people will be  
more likely to move to a better suited place if asked to.


(Just my thoughts, I am by no means a sociology expert.)


Johnny

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

RE: PROPOSAL schema.openid.net for AX (and other extensions)

[Recordon, David]

I think it is great that there is new and innovative work in what you've
been doing.  I would also think that it would benefit the entire
user-centric (and even non-user-centric) community to take advantage of
this work regardless of the technology.  By having it rooted on
openid.net, I think there will be aversion to doing so and other
communities will rather jump to the conclusion that the OpenID community
is yet again reinventing the wheel by defining common core attributes.
This is what I want to avoid.

By doing this in a neutral location, not tied to a specific identity
technology, it removes this concern as well as does more good for the
entire ecosystem.  If the ID Schemas project is not the right place to
do it, then I see no reason not to create one; I would be happy to front
the cost of a domain name if needed.

I'd also think this would be something worth discussing at IIW when the
entire community comes together.  I would really like to see this be
something that can be used by OpenID, CardSpace, Higgins, SAML, etc.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 06, 2007 1:07 PM
To: Recordon, David
Cc: OpenID specs list; Paul Trevithick; Mark Wahl
Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)

If there was something out there already, I would propose we used it.  
There is not.

Just like the SAML crowd has accused the OpenID crowd of reinventing an
identity protocol (AKA reinventing the wheel) -- the AX proposal has
some unique concepts that people like Paul and Mark think are quite
innovative. Other schemas don't support them.

I have cc'ed Paul and Mark in case they can point to some new work that
we can take advantage of today.

Other responses inserted:

On 6-Apr-07, at 11:49 AM, Recordon, David wrote:

> As I've stated in the past, I have no problem with using 
> schema.openid.net to define attributes such as the authoritative URI 
> for an OpenID URL, i-name, etc.
>
> I do have a problem with using this namespace to define an attribute 
> such as a First Name.  I do not feel that this community should be 
> dealing with all of the issues such as First Name vs. Given Name, as 
> that is not where the expertise is, let alone it has been done in the 
> past.  I also strongly believe that due to the number of other 
> definitions of these attributes, either we as a community should 
> decide to use one of them or work with a project such as ID Schemas to

> create a set of URIs not tied to the OpenID project that solves both 
> our needs and the needs of others.  I do not particularly care where 
> this work would happen and as I've said in the past, I'd be fine with 
> someone just buying a domain to do the work to preserve the speed for 
> getting this bootstrapped while not tying it to OpenID.

If really don't care, then you should not care if it is happening in
OpenID then.

>
> First Name:
>  - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

This URL could be used. To date they have not made these self  
describing. Who knows what this is? The AX proposal is to make the  
URLs describing. This makes it easier for programmers to know what it  
is they are working with.

>  - http://xmlns.com/foaf/0.1/firstName
>  - http://xmlns.com/foaf/0.1/givenname

Both of these are elements in a larger XML document. This is not the  
model of AX.

>  - http://en.wikipedia.org/wiki/First_name

While intriguing to have wikiality define terms, this is not  
practical since the definition needs to be static or code will break

>
> I'm sure if Paul Trevithick or Mark Whal join this conversation they'd
> be able to highlight even more URI definitions of a First Name than I
> was in a cursory search.  This also isn't including all of the work  
> done
> for things such as LDAP, vCard, or others listed at
> http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining  
> what
> these schema attributes are and mean.

Most other work has created closed schemas. The AX proposal is an  
open schema where anyone can define a new attribute and each one is  
self describing.

>
> If we want to create URLs for attributes from an existing schema (such
> as LDAP or vCard) since easy URLs do not currently exist, then that is
> one thing.  Creating an entirely new definition of commonly used
> attributes IMHO is unacceptable.

People keep doing it for a variety of reasons. People keep inventing  
new programming languages.


>   We should be reusing anything that we
> can, not inventing something new especially given the complexity of  
> this
> particular task.

The task has largely been done. Still need to finalize the meta-data  
file format.

>
> I'm not sure what more I can do to urge this community to not reinvent
> the wheel in this area.

See comment at top. AX does not need a wheel. AX needs a wing. Wings  
don't exist right now.

-- Dick




___
specs mailing list
s

Re: Logout

[Josh Hoyt]

On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
> I could only go only till Aug 2006 on the mail archives here:
> http://openid.net/pipermail/specs/ and nothing found specifically on
> "logout' (atleast based on the thread subjects).

I'd also search the other mailing lists, because the discussions on
each of them tend to blur together (spec issues on general, and so
on). I'll have to remember to bring the search issue up the next time
someone suggests Yet Another Mailing List.

> Any one know how and where we could get older archives ?

http://lists.danga.com/pipermail/yadis/

Can we get a copy of these archives on openid.net?

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

Re: Attribute Exchange 1.0 svn revision 295 review

[Josh Hoyt]

On 4/6/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I agreed with you previously that the response being able to work
> either way if the request can. Sorry if that was not clear.

Great. That will simplify the code.

Given this change, is there still the need to have the special case
for sending an empty string as a null value? That case can be covered
(explicitly) by using count=0, even if omitting a requested value is
still illegal (see below).

> > Another restriction on the response message is that you have to send
> > responses even if they are empty. Can you give the rationale for
> > requiring the fields with no values to be sent?
>
> I am unclear on what your question is. Would you clarify?

Section 5.2 states:

"A response parameter MUST be sent for each requested attribute alias."

"This enables the RP to know that the OP did process the request."

Does it that the relying party will know that each requested attribute
was processed, or the request as a whole? And what would the relying
party be able to do if it got a response that indicated that the OP
had not processed the request? (send a bug report?)

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

Re: Attribute Exchange 1.0 svn revision 295 review

[Dick Hardt]

On 5-Apr-07, at 4:48 PM, Josh Hoyt wrote:

> On Apr 5, 2007 at 8:41 AM, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> > There is no way to say "I want as many of X as you have, and I  
>> don't
>> > care how many that is"
>>
>> Good point. Perhaps have  a magic value like -1 to indicate as many
>> as the user will release?
>> I had thought the RP would likely have a maximum they would want in
>> most situations.
>
> Generally, yes, although when we were discussing the spec, we talked
> about using one pass of attribute exchange to get all of the available
> attributes and another pass to request the attributes themselves. When
> requesting the available attributes, it seems like you'd want to say
> "give me all the attributes that are available" instead of "give me up
> to 500 available attributes," but I could be wrong.
>
> It might be good to give a bound on the response size for every
> request, although in cases such as above, it might be useful to the
> relying party to know if there were values that overflowed the limit.
> It wouldn't be difficult to add a flag, but I'm also not sure whether
> it would be worth the extra complexity.

Our experience to date has been that we don't have multiple so far. I  
am sure there will be some use cases that do.

Good question if those will be limited or not. Our thinking had been  
that some applications may have 4 slots for attributes in the DB, so  
only would ask for up to 4 attributes.


>
>
>
>> > There is the issue that I brought up in a separate message where
>> > count=1 is different from not specifying a count, even though they
>> > both mean 1 or 0 values.
>>
>> The perl way would be to have "more then one way to do it" and allow
>> both methods to mean the same thing.
>>
>> The python way would be "there is one way to do it" and not allow
>> count=1 in a request
>
> Well, clearly it's better to have one way to do it. But seriously, the
> main problem that I have with it is that the specification prescribes
> the response format based on the request format. That is, my code has
> to keep track of whether the request used count=1 or just didn't
> specify a count, instead of just recording that the request asked for
> one value, so that the later code can know how to encode the value. If
> there's really more than one way to do it, you should be allowed to do
> it either way.

I agreed with you previously that the response being able to work  
either way if the request can. Sorry if that was not clear.

>
> I'm guessing that you made that restriction on the response format so
> that relying parties can know what the form of the response will be.
> Is that correct?

It was on the grounds that this is what the RP had requested, so the  
OP should do the same. But I agree with you that allowing either is  
preferred, and am also ok with there only being one way of asking for  
a single value. No strong opinion here on that.

> Another restriction on the response message is that you have to send
> responses even if they are empty. Can you give the rationale for
> requiring the fields with no values to be sent?

I am unclear on what your question is. Would you clarify?

-- Dick


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

Re: Logout

[Dick Hardt]

The was a discussion was on the user-experience list called single  
sign out

http://openid.net/pipermail/user-experience/2006-November/subject.html

I wrote up a list of issues we had seen at Sxip and our user  
experience testing that indicated it was not a high value feature

-- Dick

On 6-Apr-07, at 12:59 PM, Praveen Alavilli wrote:

> I could only go only till Aug 2006 on the mail archives here:
> http://openid.net/pipermail/specs/ and nothing found specifically on
> "logout' (atleast based on the thread subjects).
>
> Any one know how and where we could get older archives ?
>
> thx
> Praveen
>
> Josh Hoyt wrote:
>> On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
>>> well with OpenID atleast, I think we can easily design a logout
>>> extension, [...]
>>> Any reason why something like this was not incorporated into the
>>> specs yet ?
>>
>> There is not general agreement on how this feature should be
>> implemented, or even exactly how it should work. Anyone care to  
>> search
>> back through the list archives and dig up the many previous
>> discussions of this topic? It'd be useful to the discussion to gather
>> the previous discussions together and make a wiki page about sign-out
>> with links to the previous discussions and a summary of the issues  
>> and
>> possible solutions to those issues (rather than a proposal).
>>
>> Josh
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

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

Logout

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

In thinking about this, wouldn't it be interesting if the RP could return a URL 
that the selector could callback on? Of course this would be optional. 


*
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

Re: PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

If there was something out there already, I would propose we used it.  
There is not.

Just like the SAML crowd has accused the OpenID crowd of reinventing  
an identity protocol (AKA reinventing the wheel) -- the AX proposal  
has some unique concepts that people like Paul and Mark think are  
quite innovative. Other schemas don't support them.

I have cc'ed Paul and Mark in case they can point to some new work  
that we can take advantage of today.

Other responses inserted:

On 6-Apr-07, at 11:49 AM, Recordon, David wrote:

> As I've stated in the past, I have no problem with using
> schema.openid.net to define attributes such as the authoritative  
> URI for
> an OpenID URL, i-name, etc.
>
> I do have a problem with using this namespace to define an attribute
> such as a First Name.  I do not feel that this community should be
> dealing with all of the issues such as First Name vs. Given Name, as
> that is not where the expertise is, let alone it has been done in the
> past.  I also strongly believe that due to the number of other
> definitions of these attributes, either we as a community should  
> decide
> to use one of them or work with a project such as ID Schemas to  
> create a
> set of URIs not tied to the OpenID project that solves both our needs
> and the needs of others.  I do not particularly care where this work
> would happen and as I've said in the past, I'd be fine with someone  
> just
> buying a domain to do the work to preserve the speed for getting this
> bootstrapped while not tying it to OpenID.

If really don't care, then you should not care if it is happening in  
OpenID then.

>
> First Name:
>  - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

This URL could be used. To date they have not made these self  
describing. Who knows what this is? The AX proposal is to make the  
URLs describing. This makes it easier for programmers to know what it  
is they are working with.

>  - http://xmlns.com/foaf/0.1/firstName
>  - http://xmlns.com/foaf/0.1/givenname

Both of these are elements in a larger XML document. This is not the  
model of AX.

>  - http://en.wikipedia.org/wiki/First_name

While intriguing to have wikiality define terms, this is not  
practical since the definition needs to be static or code will break

>
> I'm sure if Paul Trevithick or Mark Whal join this conversation they'd
> be able to highlight even more URI definitions of a First Name than I
> was in a cursory search.  This also isn't including all of the work  
> done
> for things such as LDAP, vCard, or others listed at
> http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining  
> what
> these schema attributes are and mean.

Most other work has created closed schemas. The AX proposal is an  
open schema where anyone can define a new attribute and each one is  
self describing.

>
> If we want to create URLs for attributes from an existing schema (such
> as LDAP or vCard) since easy URLs do not currently exist, then that is
> one thing.  Creating an entirely new definition of commonly used
> attributes IMHO is unacceptable.

People keep doing it for a variety of reasons. People keep inventing  
new programming languages.


>   We should be reusing anything that we
> can, not inventing something new especially given the complexity of  
> this
> particular task.

The task has largely been done. Still need to finalize the meta-data  
file format.

>
> I'm not sure what more I can do to urge this community to not reinvent
> the wheel in this area.

See comment at top. AX does not need a wheel. AX needs a wing. Wings  
don't exist right now.

-- Dick




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

Re: Logout

[Praveen Alavilli]

I could only go only till Aug 2006 on the mail archives here: 
http://openid.net/pipermail/specs/ and nothing found specifically on 
"logout' (atleast based on the thread subjects).

Any one know how and where we could get older archives ?

thx
Praveen

Josh Hoyt wrote:
> On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
>> well with OpenID atleast, I think we can easily design a logout
>> extension, [...]
>> Any reason why something like this was not incorporated into the 
>> specs yet ?
>
> There is not general agreement on how this feature should be
> implemented, or even exactly how it should work. Anyone care to search
> back through the list archives and dig up the many previous
> discussions of this topic? It'd be useful to the discussion to gather
> the previous discussions together and make a wiki page about sign-out
> with links to the previous discussions and a summary of the issues and
> possible solutions to those issues (rather than a proposal).
>
> Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Logout

[Johannes Ernst]

On Apr 6, 2007, at 12:13, Praveen Alavilli wrote:
Any reason why something like this was not incorporated into the  
specs yet ?


We just needed a volunteer like you to take it on ;-) ;-)




Johannes Ernst
NetMesh Inc.





 http://netmesh.info/jernst

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

Re: Logout

[Josh Hoyt]

On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
> well with OpenID atleast, I think we can easily design a logout
> extension, [...]
> Any reason why something like this was not incorporated into the specs yet ?

There is not general agreement on how this feature should be
implemented, or even exactly how it should work. Anyone care to search
back through the list archives and dig up the many previous
discussions of this topic? It'd be useful to the discussion to gather
the previous discussions together and make a wiki page about sign-out
with links to the previous discussions and a summary of the issues and
possible solutions to those issues (rather than a proposal).

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

Re: Logout

[Praveen Alavilli]

well with OpenID atleast, I think we can easily design a logout 
extension, where an RP can register it's logout handler with OP during 
login flow (checkid_immediate/checkid_setup) and the OP could call each 
of the RP's logout handlers (in the browser) that are registered with 
the current session when a user logs out from the OP. Ofcourse this also 
requires a new logout mode supported by OP, which an RP can call when a 
user wants to logout from the RP itself. The OP then can provide options 
to the user whether to sign out from one RP or from all. 

Any reason why something like this was not incorporated into the specs yet ?

thx
Praveen




Johannes Ernst wrote:
> That might be hard from a usability perspective, and in my experience, 
> the underlying user requirement tends to be a variation of "I am about 
> to go to lunch with the guys waiting in the hall way, log me out of 
> all apps I'm currently logged in but take no more than 10 seconds 
> because otherwise they will leave without me. Or at least the critical 
> ones." (which is where it gets hard to design this right) Where 
> sessions come in is that again from a usability perspective, the user 
> should not have to "log out" from apps that he currently isn't logged 
> into (because the session expired, for example).
>
>
> On Apr 6, 2007, at 10:51, McGovern, James F ((HTSC, IT)) wrote:
>
>> I would think that you wouldn't need to track the notion of a session 
>> but have something where the selector that tracked where the card was 
>> previously sent in terms of a list would allow you to graphically 
>> send another event. You could optionally walk a list based on each card.
>>
>> -Original Message-
>> *From:* Johannes Ernst [mailto:[EMAIL PROTECTED]
>> *Sent:* Friday, April 06, 2007 12:29 PM
>> *To:* McGovern, James F (HTSC, IT)
>> *Cc:* specs@openid.net 
>> *Subject:* Re: Logout
>>
>> So far, neither OpenID nor CardSpace define the notion of a
>> session, so no common logout is possible within the standard
>> protocols.
>>
>> What we do in our code at NetMesh is to add a convention where
>> RP-URL?lid=OPENID
>> is the same thing as "submitted OpenID URL in the first form", to
>> which the RP-URL responds with a redirect to the OP, while
>> RP-URL?lid=
>> means "become anonymous again" aka "logout".
>>
>> There are substantial usability issues with common logout in a
>> decentralized, "internet-scale" approach, however, that nobody
>> has really solved as far as I know.
>>  
>>
>>
>>
>> *
>> 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
>
> =
> 
>
> ___
> 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: PROPOSAL schema.openid.net for AX (and other extensions)

[Recordon, David]

As I've stated in the past, I have no problem with using
schema.openid.net to define attributes such as the authoritative URI for
an OpenID URL, i-name, etc.

I do have a problem with using this namespace to define an attribute
such as a First Name.  I do not feel that this community should be
dealing with all of the issues such as First Name vs. Given Name, as
that is not where the expertise is, let alone it has been done in the
past.  I also strongly believe that due to the number of other
definitions of these attributes, either we as a community should decide
to use one of them or work with a project such as ID Schemas to create a
set of URIs not tied to the OpenID project that solves both our needs
and the needs of others.  I do not particularly care where this work
would happen and as I've said in the past, I'd be fine with someone just
buying a domain to do the work to preserve the speed for getting this
bootstrapped while not tying it to OpenID.

First Name:
 - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
 - http://xmlns.com/foaf/0.1/firstName
 - http://xmlns.com/foaf/0.1/givenname
 - http://en.wikipedia.org/wiki/First_name

I'm sure if Paul Trevithick or Mark Whal join this conversation they'd
be able to highlight even more URI definitions of a First Name than I
was in a cursory search.  This also isn't including all of the work done
for things such as LDAP, vCard, or others listed at
http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining what
these schema attributes are and mean.

If we want to create URLs for attributes from an existing schema (such
as LDAP or vCard) since easy URLs do not currently exist, then that is
one thing.  Creating an entirely new definition of commonly used
attributes IMHO is unacceptable.  We should be reusing anything that we
can, not inventing something new especially given the complexity of this
particular task.

I'm not sure what more I can do to urge this community to not reinvent
the wheel in this area.

--David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Friday, April 06, 2007 10:27 AM
To: OpenID specs list
Subject: PROPOSAL schema.openid.net for AX (and other extensions)

OpenID Attribute Exchange (AX) uses URLs to uniquely identity
attributes. The URLs are resolvable to provide meta data that is both
machine and human readable.

In order to do anything useful with AX, some commons identity attributes
need to be defined.

I would propose that we start off using URLs based off of
schema.openid.net.

The Metadata model has provisions for stating that a given URL is  
equivalent to another one, so that if and when a more authoritative   
source is available, the schema.openid.net URLs can reference a source
that would be considered more appropriate. ie. we are not locked forever
to the schema.openid.net domain.

Is there a better domain that could be used? Likely, but as a community
we have control over openid.net and we can make this happen now so that
we can move forward with development.

Issues?

-- 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: Logout

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

I think this means that the Selector MUST implement async firing capability. A 
user should not wait nor should this be syncronous. Likewise if a session has 
already been logged out, then by "contract" then the RP should simply ignore.

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 2:25 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: Logout


That might be hard from a usability perspective, and in my experience, the 
underlying user requirement tends to be a variation of "I am about to go to 
lunch with the guys waiting in the hall way, log me out of all apps I'm 
currently logged in but take no more than 10 seconds because otherwise they 
will leave without me. Or at least the critical ones." (which is where it gets 
hard to design this right) Where sessions come in is that again from a 
usability perspective, the user should not have to "log out" from apps that he 
currently isn't logged into (because the session expired, for example). 


On Apr 6, 2007, at 10:51, McGovern, James F ((HTSC, IT)) wrote:


I would think that you wouldn't need to track the notion of a session but have 
something where the selector that tracked where the card was previously sent in 
terms of a list would allow you to graphically send another event. You could 
optionally walk a list based on each card.

-Original Message-
From: Johannes Ernst [ mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 12:29 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: Logout


So far, neither OpenID nor CardSpace define the notion of a session, so no 
common logout is possible within the standard protocols. 


What we do in our code at NetMesh is to add a convention where
RP-URL?lid=OPENID
is the same thing as "submitted OpenID URL in the first form", to which the 
RP-URL responds with a redirect to the OP, while
RP-URL?lid=
means "become anonymous again" aka "logout".


There are substantial usability issues with common logout in a decentralized, 
"internet-scale" approach, however, that nobody has really solved as far as I 
know.
 



*
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


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

Re: Logout

[Johannes Ernst]

That might be hard from a usability perspective, and in my  
experience, the underlying user requirement tends to be a variation  
of "I am about to go to lunch with the guys waiting in the hall way,  
log me out of all apps I'm currently logged in but take no more than  
10 seconds because otherwise they will leave without me. Or at least  
the critical ones." (which is where it gets hard to design this  
right) Where sessions come in is that again from a usability  
perspective, the user should not have to "log out" from apps that he  
currently isn't logged into (because the session expired, for example).



On Apr 6, 2007, at 10:51, McGovern, James F ((HTSC, IT)) wrote:

I would think that you wouldn't need to track the notion of a  
session but have something where the selector that tracked where  
the card was previously sent in terms of a list would allow you to  
graphically send another event. You could optionally walk a list  
based on each card.

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 12:29 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: Logout

So far, neither OpenID nor CardSpace define the notion of a  
session, so no common logout is possible within the standard  
protocols.


What we do in our code at NetMesh is to add a convention where
RP-URL?lid=OPENID
is the same thing as "submitted OpenID URL in the first form", to  
which the RP-URL responds with a redirect to the OP, while

RP-URL?lid=
means "become anonymous again" aka "logout".

There are substantial usability issues with common logout in a  
decentralized, "internet-scale" approach, however, that nobody has  
really solved as far as I know.




** 
***

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


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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johnny Bufu]

On 6-Apr-07, at 10:34 AM, Johannes Ernst wrote:
>> Well, as one of the people that wrote the documents. We decided that
>> having separate documents was better. Thanks for sharing your
>> opinion. I have a different opinion.
>
> For somebody who currently doesn't have an opinion on this subject,  
> could you briefly describe the rationale for your view?

If I'm only interested in moving attributes around (the current case  
of the OpenID libraries), I am not interested at all what the  
semantic of the attributes are, just in moving them from A to B. I'll  
let the parties at the both ends of the transaction look up the  
metadata and handle them based on that.

On the other hand when I read a (new) spec it's a lot easier for me  
if there are clearly outlined components with which I don't  
necessarily have to deal at the same time; especially if the  
components have other uses beside the initial combination.

These two seem to have been the rationale of the recent discussions  
about splitting the OpenID spec into core/discovery/etc., which  
seemed to make sense to a number of people (I'm just not sure if it's  
worth / good tactical move at this stage).


Johnny

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

RE: Logout

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

I would think that you wouldn't need to track the notion of a session but have 
something where the selector that tracked where the card was previously sent in 
terms of a list would allow you to graphically send another event. You could 
optionally walk a list based on each card.

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 12:29 PM
To: McGovern, James F (HTSC, IT)
Cc: specs@openid.net
Subject: Re: Logout


So far, neither OpenID nor CardSpace define the notion of a session, so no 
common logout is possible within the standard protocols. 


What we do in our code at NetMesh is to add a convention where
RP-URL?lid=OPENID
is the same thing as "submitted OpenID URL in the first form", to which the 
RP-URL responds with a redirect to the OP, while
RP-URL?lid=
means "become anonymous again" aka "logout".


There are substantial usability issues with common logout in a decentralized, 
"internet-scale" approach, however, that nobody has really solved as far as I 
know.
 



*
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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Josh Hoyt]

On 4/6/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> On 5-Apr-07, at 9:18 AM, Recordon, David wrote:
> > I'm fine with doing things differently, I'm not arguing that a
> > metadata
> > format should not be created, just that IMHO for simplicity sake of
> > reading the AX documents this format description should be merged into
> > the core protocol spec.  If down the road it should be split out
> > then it
> > always can be.
>
> Well, as one of the people that wrote the documents. We decided that
> having separate documents was better. Thanks for sharing your
> opinion. I have a different opinion.

Having started an implementation, I'm glad that metadata is not part
of the core, because metadata is not necessary for a wide range of
applications. I think it will be useful eventually, but I'm glad that
I can implement the core completely without thinking about metadata.
If metadata were part of the core (even optionally!) I might not have
even started writing code.

I do wish that this thread did not contain so much bickering.

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Johannes Ernst]

On Apr 6, 2007, at 10:21, Dick Hardt wrote:

On 5-Apr-07, at 9:18 AM, Recordon, David wrote:


... IMHO for simplicity sake of
reading the AX documents this format description should be merged  
into

the core protocol spec.  If down the road it should be split out
then it always can be.


Well, as one of the people that wrote the documents. We decided that
having separate documents was better. Thanks for sharing your
opinion. I have a different opinion.


For somebody who currently doesn't have an opinion on this subject,  
could you briefly describe the rationale for your view?




Johannes Ernst
NetMesh Inc.





 http://netmesh.info/jernst

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

PROPOSAL schema.openid.net for AX (and other extensions)

[Dick Hardt]

OpenID Attribute Exchange (AX) uses URLs to uniquely identity  
attributes. The URLs are resolvable to provide meta data that is both  
machine and human readable.

In order to do anything useful with AX, some commons identity  
attributes need to be defined.

I would propose that we start off using URLs based off of  
schema.openid.net.

The Metadata model has provisions for stating that a given URL is  
equivalent to another one, so that if and when a more authoritative   
source is available, the schema.openid.net URLs can reference a  
source that would be considered more appropriate. ie. we are not  
locked forever to the schema.openid.net domain.

Is there a better domain that could be used? Likely, but as a  
community we have control over openid.net and we can make this happen  
now so that we can move forward with development.

Issues?

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Dick Hardt]

On 5-Apr-07, at 9:24 AM, Recordon, David wrote:

> Dick, see my other message but this is not about ME stopping you!
>>> We wanted to publish them on the website so that other people could
>>> look at them, but you did not want to do that, and you control the
>>> domain.
>>
>> Dick, that isn't a fair statement at all.  It is not my decision to
>> make if schemas.openid.net should be created and the content you're
>> proposing put there.  I've asked you multiple times to have a
>> conversation on this list ending in a formal vote (like we've done
>> for many other spec decisions) to make this decision.  If I've missed
>> this vote then please point me at it.
>
> I'm quite honestly not sure what more to say.  If you want to see this
> work happen then you need to take the initiative and make it happen.
> You can't just expect to post a few messages to the ID Schemas list  
> and
> have them magically start working.
>
> I'm all about taking advantage of existing momentum, but I have a hard
> time seeing anyone who cares about AX being unwilling to have this
> discussion as a part of the ID Schemas community.  If there is anyone,
> I'd certainly like to understand the reasons why (beyond it being
> "hard").

We wrote a spec.

We have working code.

Other people have developed code as well.

We need to publish a schema so that we can systems talk to each other.

If *you* would like to see the work done over in ID Schemas, then  
*you* can work to make it happen there. The same for other people. If  
the work shifts to there, I am fine with it. Right now, I'm fine with  
doing the work here on the OpenID specs list.

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

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

[Dick Hardt]

On 5-Apr-07, at 9:18 AM, Recordon, David wrote:

>> I don't think this is really that important of a point given all the
>> other things we need to do. People are doing to do things different
>> then you would, but get the same result -- is that ok?
> I'm fine with doing things differently, I'm not arguing that a  
> metadata
> format should not be created, just that IMHO for simplicity sake of
> reading the AX documents this format description should be merged into
> the core protocol spec.  If down the road it should be split out  
> then it
> always can be.

Well, as one of the people that wrote the documents. We decided that  
having separate documents was better. Thanks for sharing your  
opinion. I have a different opinion.

>
>> We wanted to publish them on the website so that other people could
>> look at them, but you did not want to do that, and you control the
> domain.
> Dick, that isn't a fair statement at all.  It is not my decision to  
> make
> if schemas.openid.net should be created and the content you're  
> proposing
> put there.  I've asked you multiple times to have a conversation on  
> this
> list ending in a formal vote (like we've done for many other spec
> decisions) to make this decision.  If I've missed this vote then  
> please
> point me at it.

I don't recall you ever actually telling me to have a vote. You  
stated you did not want to do it and to find some other home.

I wanted to setup the schemas so that people could see how it worked,  
then I could actually get constructive comments back from the list  
and have something tangible to vote on.

I have no ideal what the "formal vote" process on OpenID. The only  
that I know of that is documented is the process for approving the  
OpenID Authentication 2.0 specs.

I'll post a question to the list if that is what you want.

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

Re: Logout

[Johannes Ernst]

So far, neither OpenID nor CardSpace define the notion of a session,  
so no common logout is possible within the standard protocols.


What we do in our code at NetMesh is to add a convention where
RP-URL?lid=OPENID
is the same thing as "submitted OpenID URL in the first form", to  
which the RP-URL responds with a redirect to the OP, while

RP-URL?lid=
means "become anonymous again" aka "logout".

There are substantial usability issues with common logout in a  
decentralized, "internet-scale" approach, however, that nobody has  
really solved as far as I know.



On Apr 6, 2007, at 9:15, McGovern, James F ((HTSC, IT)) wrote:

Curious question that someone asked that I didn't know the answer  
to. OpenID/Cardspace allow for easy SSO into web sites. How does  
one perform the equivalent logout from an Identity Selector?




** 
***

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


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

Re: Logout

[frumioj]

Hi James,

McGovern, James F (HTSC, IT) wrote:
> Curious question that someone asked that I didn't know the answer to.
> OpenID/Cardspace allow for easy SSO into web sites. How does one perform
> the equivalent logout from an Identity Selector?

Logout from the client side would be possible only if an RP or IdP
supported some protocol for logout that could then be used by the client
(whether it be the web browser, Cardspace or something else).

Typical approaches to logout in the web-browser world involve simply
providing a link on a web page that allows the user to press the link to
logout. Of course, logging out at one RP doesn't mean you're logged out
with the IdP or all the other RPs you might be logged in with.

SAML 2 has a "single logout" protocol, but I don't believe that OpenID
currently specifies something like that.

Regards,

- John

> 
> 
> 
> *
> 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

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

Verisign Customer Authentication Service

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

VeriSign's Consumer Authentication Service authenticates customers by using 
real-time automation processes in combination with unique interactive question. 
Once consumers are properly authenticated by CAS, enterprises can be assured of 
their identity, and they can
execute secure business transactions on the Internet.

What is intriguing is that they have an identity verification service which 
feels like the attestation I seek. What would it take for the Verisign Identity 
Verification Service to attest that the chosen card is digitally signed proving 
who they say they are.


*
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

Logout

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

Curious question that someone asked that I didn't know the answer to. 
OpenID/Cardspace allow for easy SSO into web sites. How does one perform the 
equivalent logout from an Identity Selector?


*
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

Re: Web Access Management

[Martin Atkins]

McGovern, James F (HTSC, IT) wrote:
> Are you saying that the large vendors aren't participating because OpenID 
> forces too many things to be open?
> 

No, I'm saying that large vendors aren't participating because it's not 
clear exactly what the expectations are for openness.

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

Web Access Management

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

Are you saying that the large vendors aren't participating because OpenID 
forces too many things to be open? Having large companies on-board will 
accelerate adoption and whatever the impediments to this happening should be of 
higher priority than discussion around specifications.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Martin Atkins
> Sent: Thursday, April 05, 2007 4:41 PM
> To: specs@openid.net
> Subject: Re: Web Access Management
> 
> Hans Granqvist wrote:
> >> Ping demoed OpenID technology at RSA.
> >>
> >> I hear Novell and IBM are looking at supporting OpenID.
> >>
> >> Microsoft has said they will in future products.
> >>
> >> Oracle and CA are following OpenID.
> >>
> >> So, yes. :-)
> >>
> >
> > I'm curious why almost all of these companies are non-existent
> > on the mailing lists.  Any insights?
> >
> 
> It seems that at this time the uncertain policies for issues such as
> patents and trademarks surrounding OpenID are putting off larger
> companies from directly participating.
> 
> This is a current hot-topic for the OpenID Foundation, since getting
> such companies fully on board would likely be beneficial.
> 
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs




*
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

Web Access Management

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

Are there special considerations for either relying parties when they may be 
protected by Web Access Management products? For example, if I initially sign 
onto a web site using OpenID, I still will need for the Web Access Management 
product to create a secure cookie that contains a session identifier. 
Minimally, the product may have the option of taking information from any card 
and putting it into an unencrypted cookie. Any issues?


*
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