RE: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
Thanks, definitely am!  Just catching up on a lot of email now.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 13, 2007 11:05 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

 http://openid.net/specs/openid-provider-authentication-policy- 
 extension-
 1_0-01.html

Hope you're still welcoming feedback on this..

While trying to explain what PAPE is/does, I noticed that the term  
'authentication policy' is not explicitly defined in the spec (and  
how a policy differentiates from a specific authentication  
mechanism). A clear definition could help eliminate confusion between  
the two.


Johnny

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


RE: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
1) I imagine the URLs will become live at some point. :)

2) I wouldn't mind renaming it to no-shared-secrets which can also
have a corresponding less secure policy of shared-secret-second or
something like that which means the user provided a shared secret only
after first providing something like a client side certificate.  Also,
the URLs are versioned (by date) which allows their definitions to
evolve.

3) Like the http://schemas.openid.net/pape/policies/2007/06/none
approach, it was required so a RP could tell the difference between a
Provider not supporting the extension in the response versus not using
any policies.

4) Yeah.

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans
Granqvist
Sent: Friday, June 22, 2007 3:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

A few comments:

* Would be great if all the namespace URLs resolved into live links.
It always helps in the XML world and probably would in here too.

* Section 4 Defined Authentication Policies

We've talked about this before, but I just want to restate that it is
a bad idea to name a policy based on its inferred values.
Phishing-resistant implies a quality that is not necessarily
measurable. Quality can also shift over time.

The other policies are measurable (you can count number of  factors
used, for example).

I'd strongly advise renaming phishing-resistant to something like
no-secrets-shared (you can probably come up with a more succinct
term)

* 5.2 response params

Requiring openid.pape.auth_policies to have a null value if no
policies were met seems odd (and it may break processing where a value
is always expected by the parser). Better would be to explicitly state
that no policies were met by a predefined literal or URL. For example
openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/0
6/none

* Section 7 Examples

I wanted to see some examples on how PAPE is used in the messages.
Maybe add a few?


I like the work. However, the spec is optional. I was hoping
finalizing auth 2.0 would be top priority.

-Hans

On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote:
 Over the past few weeks I've been working on the OpenID Provider
 Authentication Policy Extension which is designed to replace the work
I
 did last year with the Assertion Quality Extension.

 Generally, the goal of this extension is to provide Relying Parties
with
 more information about how the End User authenticated to their
Provider.
 This is done by a mix of the RP requesting certain policies (such as
 phishing-resistant or multi-factor), the OP helping the End User
through
 the authentication process, and then in the OpenID Authentication
 response including the policies that were met as well as optionally a
 strength level for the overall authentication.

 This extension doesn't speak at all toward trust of the End User or
 Provider, so RPs will still have to decide if they believe the
 information returned about the authentication in the response.

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.


http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.html

http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.txt

 Thanks,
 --David
 ___
 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: OpenID Provider Authentication Policy Extension

2007-07-21 Thread Recordon, David
5.1 
1) Clarified.

2  3) Changed the MUST to a SHOULD, since the intent was never to
restrict what a user could do.

4) Changed to Integer

5.2
1) What is the use-case for this?  As the parameter always describes the
policies returned in pape_auth_policies, the Provider should always know
how long ago the user authenticated within the session.

2) I'm fine with time coming back instead of number of seconds.

3) Changed to integer.

Thanks,
--David


 -Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 28, 2007 7:31 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

David,

On 22-Jun-07, at 9:46 AM, Recordon, David wrote:
 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

Here are the issues that came up while I implemented PAPE in  
openid4java:


5.1 Request Parameters

- Is preferred_auth_policies REQUIRED? Assume yes, but not clearly  
spelled out.

- the OP MUST authenticate the End User for this request.

What if the OP / user don't want to re-authenticate, and have reasons  
to continue their session with the previous / old auth? (For example  
user changed his mind at the OP about buying the book from amazon,  
and declines the OP's request to re-authenticate).

- The OP should realize that not adhering to the request for re- 
authentication... implies there is an alternative to the above  
(other than breaking the protocol). Maybe the MUST above should be a  
SHOULD?

- (max_)auth_age is defined as numeric. Is there value for allowing  
floating-point numbers here? Would be simpler to be an integer.


5.2 Response Parameters

- auth_age: What should the value be if the OP did not actively  
authenticate the user for the current session? Suggesting unknown  
as a special value for this.

- auth_age: Since the message may spend a (not-insignificant) time  
after it's created (by the library)
before it's put on the wire
on the wire
while it's being processed by the RP
a timestamp value may be better suited here (rename it to auth_time  
maybe?). This way the RP will be able to determine the auth_age at  
any time (e.g. when it actually needs to perform the sensitive  
operation). Could use the formating used for nonces (from RFC3339).

- nist_auth_level: Numeric value - probably was meant as integer  
value.


Thanks,
Johnny

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


FW: Identifier Liftetime (WAS: RE: [OpenID] Recycling OpenIDs)

2007-07-08 Thread Recordon, David
Just food for thought some day...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Evan Prodromou
Sent: Monday, June 11, 2007 5:31 AM
To: openid-general
Subject: Re: [OpenID] Recycling OpenIDs

On Sat, 2007-09-06 at 09:47 -0400, Evan Prodromou wrote:

 If relying parties require some high level of authentication, we have 
 ways to specify that.

I think I should have been more specific here: the best way to solve the
ID lifetime problem is to add a parameter to AQE that lets the OP
specify the expected lifetime of the identifier.

enroll.lifetime - integer, time in days that the OP expects the
identifier to identify the current principal. Some sample
values:

  * 0: the identifier could belong to a different principal
at any time. For example, anonymous OPs or OPs where
users can manually change their own identifiers to any
unused value at will.
  * Session: the identifier will belong to the current
principal for the duration of the principal's browser
session.
  * 730: the OP recycles identifiers if they haven't been
used in 2 years.
  * Inf: the OP's policy is that the identifier will be used
for only one principal. Infinity is an ideal
expectation, subject to the lifetime of the OP, of the
OpenID protocol, of the Internet, and of the universe.
More immediately, there may be changes to the policy in
the future.

Note that there is no way to specify non-zero lifetimes shorter
than one day, and that the special non-integer strings Session
and Inf are acceptable values.

I'm actually not sure how to implement an OP that would use Session --
possibly with a browser plugin? -- but I included it for completeness.

-Evan

--
Evan Prodromou [EMAIL PROTECTED]
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Writeup of XRDS Canonical ID verification for URLs and XRIs

2007-06-14 Thread Recordon, David
That new wording for the Yadis bit looks good to me!

-Original Message-
From: =drummond.reed [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 14, 2007 4:49 PM
To: 'Johnny Bufu'
Cc: specs@openid.net; Recordon, David
Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs


 On 13-Jun-07, at 7:04 PM, =drummond.reed wrote:

 With the Yadis specification now included in section 4 of XRI  
 Resolution
 Working Draft 11 (see
 http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris  
 for a copy
 of the text of this section -- thanks to David, Johnny, and Rowan for
 feedback on the first draft)

Johnny Bufu wrote:

Drummond,

A bit more feedback on the Yadis section, hope you don't mind. 

Absolutely not. The goal has always been to make sure it specifies what
Yadis 1.0 specifies. Everyone else who cares about
URL-discovery-of-XRDS,
please do review the proposed text of this section, posted on the XRI TC
wiki at:

http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris


 The overview section (4.1) still says:

 A service hosting an XRDS document discoverable through an HTTP(S)  
 URI is only required to support one option

Which is not equivalent with the Yadis spec, 6.2.4. Initiation:

 This request MUST be either a GET or a HEAD request.

Since the client has the option to do only GET (and the server is  
required to respond), the server doesn't have a choice to support  
only HEAD. GET is required , HEAD is optional (because of the  
required fallback on the client side).

Got it. It was David who sent me the suggestion to word it that way, as
I
think he thought that the client could do either option.

David, if you agree with Johnny, then I will update the text of section
4.1
to say:

The protocol has two options: using an HTTP HEAD request to obtain a
header
with XRDS document location information (section 4.2), or using an HTTP
GET
request with content negotiation (section 4.3). A service hosting an
XRDS
document discoverable through an HTTP(S) URI MUST support the GET
option,
and MAY support the HEAD option. A client agent seeking to discover an
XRDS
document from an HTTP(S) URI MAY use either option, but MUST attempt the
GET
option if the HEAD option fails.

Let me know if you have any feedback on this wording.


 extending Canonical ID verification to cover
 any combination of URLs and XRIs is quite straightforward.

 The formal proposal is now fully written up on the XRI TC wiki. The  
 first
 link below is to the full page; the second takes you directly to  
 the example
 section.

  http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

Looks ok to me. For the OpenID spec, it seems we have two options now:

1) Use canonical IDs for URLs, and reference section 11 from the XRI  
spec for the verification part
   pros:
   addresses recycling issue
   brings in a (possibly) persistent identifier, addressing
issue B)  
here [1]
   cons:
   possible issue with defining the canonical ID (or an
alternate  
path) for HTML discovery
   need to adjust how the claimed id is handled with Yadis
discovery
   more complex than 2) (more canonical id verification
paths)

2) Adopt the fragment proposal and specify it inline [2]
   pros:
   addresses recycling issue
   simpler than 1)
   cons:
   does not address issue B here [1]


Johnny


[1] http://openid.net/pipermail/specs/2007-June/001847.html
[2] http://openid.net/pipermail/specs/2007-May/001767.html

Agreed. Good analysis. 

The XRI TC had a good discussion about this extended Canonical ID
verification model this morning, and we realized it actually adds some
additional functionality even to XRI-to-XRI relationships. We didn't
have
time to complete the discussion, but we're going to proceed rapidly with
the
goal of incorporating it into ED03 next week.

=Drummond 

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


RE: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Recordon, David
I agree that all things equal, it is reasonable to look at.

I think a lot of this in terms of where stripping versus identifier
storage happen depends a lot on the library and application.  In Rails
for example the library manages the store for associations and nonces,
and the application has to modify a table to store the identifier.  In
the stripping case, you'd then have to create a method in your
application for when you call User.identifier which strips the fragment.
In the second field case, you'd then have two fields in your database to
work with, also from the application level.

So just not sure if there really is more or less complexity from this
standpoint between the two approaches.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 10:15 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: No New DB Field Requirement? (WAS: RE: Questions about IIW
Identifier Recycling Table)


On 8-Jun-07, at 10:02 AM, Recordon, David wrote:

 I'm confused as to why a RP having to not create a new DB field is a
 requirement when looking to solve this problem.  RP's implementations
 already need to change to upgrade from 1.1 to 2.0 and this has never
 been a requirement in the past.  It certainly is nice that storage
 changes wouldn't be needed, but I don't see it as something that  
 should
 be a requirement.

My feeling was that, all other things being equal, some bits of code  
(stripping the fragment for display purposes) which ideally would go  
into the library, were preferred to requiring a schema change (to  
store the separate token) for the RPs. Not a requirement, but a  
strong preference.


Johnny

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


No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Recordon, David
I'm confused as to why a RP having to not create a new DB field is a
requirement when looking to solve this problem.  RP's implementations
already need to change to upgrade from 1.1 to 2.0 and this has never
been a requirement in the past.  It certainly is nice that storage
changes wouldn't be needed, but I don't see it as something that should
be a requirement.

Can someone shed some light on this for me?

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, June 07, 2007 5:03 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: Questions about IIW Identifier Recycling Table

On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote:
 Over the last few days I've been thinking about your Identifier
Recycling
 proposal[2], in addition to other proposals (Tokens, etc).  Assuming I
 understand things correctly, it seems as if a hybrid of the
public/private
 token approach would seem to garner the most checks, per the IIW grid.
Not
 sure if my idea is technically correct or not, so please let me know
if what
 I'm proposing falls short anywhere.  Here goes

I'm not sure I understand what's public about this. If I understand
it correctly, from the relying party's perspective, the user's account
is keyed off of the pair of the identifier and the token. This sounds
like URL + private token in that table. Am I missing something?

This approach was rejected at IIW because:

 1. An extra database field is required (whether or not the data is
transmitted using attribute exchange)

 2. There is no obvious way to tell if a user is the same user across
sites (The identifier contains a secret portion)

 3. Concern about depending on a secret for a user to be able to sign
in to a site (David's Wordpress issue)

I'm not sure which of these issues were the basis for rejecting this
approach. To me, the biggest problem with it is (2)

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


RE: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Recordon, David
The difference I see is that the current secrets can be renegotiated.
If we're working with non-public fragments then they cannot be.  If
we're working with public fragments, then I'm less concerned.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Friday, June 08, 2007 10:29 AM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: Questions about IIW Identifier Recycling Table

On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote:
If the token is publically viewable, then losing it is not an issue. I
do not share David's concern about depending on a secret, since both
the relying party and the provider already need to store secrets.

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


Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
I'm not sure if we all think we're trying to solve the same problem.
The two problems that have been discussed are:
A) Identifier recycling normally in large user-base deployments.  i.e.
insert big company needs a way to give 'TheBestUsernameEver' to a new
user if it has not been used in some period of time.
B) Losing control of your own domain name whether that be via someone
stealing it or just that you don't want to have to pay for it forever.

Have we made a decision as to if we're looking for a solution to solve
both of these problems, only A, or only B?

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


RE: The CanonicalID Approach

2007-06-08 Thread Recordon, David
Hey Johnny,
My understanding, though don't have the appropriate spec reference, is
that the process would be:

1) User enters http://daveman692.livejournal.com
2) RP fetches Yadis doc for http://daveman692.livejournal.com
3) RP sees CanonicalID of
http://www.livejournal.com/userinfo.bml?userid=1356357
3) RP fetches Yadis doc for
http://www.livejournal.com/userinfo.bml?userid=1356357
4) RP sees CanonicalID of
http://www.livejournal.com/userinfo.bml?userid=1356357 is itself
5) RP sees Ref of http://daveman692.livejournal.com and thus has
verified that the pointer goes in both directions

Will have to ask Drummond his thoughts on how fragments would be used,
since this morning it isn't clear to me.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 10:42 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: The CanonicalID Approach

Hi David,

On 7-Jun-07, at 6:31 PM, Recordon, David wrote:

 You could also, don't shudder too hard Dick :), use an i-number
 as your persistent identifier via this method though on the flip-side
 could also use a fragment if that is the approach someone would  
 like to
 take.

 The nice thing is that this method is extremely flexible in terms of
 what you use as your persistent identifier in different cases.

The question (that we will need to specify or have a clear pointer  
to) is how the canonical ID verification is done. (BTW: Was this  
section updated on Wed in the XRI draft?)

Your HTTP URL canonical ID example is straight-forward and simple. Do  
you have an example of how it would work with fragments, say:

http://openid.aol.com/daveman692 - reassignable
http://openid.aol.com/daveman692#1234 - persistent


Thanks,
Johnny


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


RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
On Jun 8, 2007, at 10:50, Johannes Ernst wrote:
 I would suggest that any solution to B is also very likely a solution

 to A.
I would agree with that statement.

--David

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 10:50 AM
To: Dick Hardt
Cc: Recordon, David; specs@openid.net
Subject: Re: Do We Agree on the Problem We're Trying to Solve?

I would suggest that any solution to B is also very likely a solution  
to A.

Anybody disagree?

If so, I'd suggest that we should either solve A and B at the same  
time, or not at all.



On Jun 8, 2007, at 10:42, Dick Hardt wrote:

 At IIW we[1] decided we wanted to solve (A) and that (B) would be
 nice to solve, but we were ok to wait for a future version to
 resolve, as when we discussed (B), resolving looked much harder then
 it seemed at first.

 I'm not certain of where we are now.

 -- Dick

 [1] those present when we met about how to solve recycling ...

 On 8-Jun-07, at 10:35 AM, Recordon, David wrote:

 I'm not sure if we all think we're trying to solve the same problem.
 The two problems that have been discussed are:
 A) Identifier recycling normally in large user-base deployments.   
 i.e.
 insert big company needs a way to give 'TheBestUsernameEver' to a
 new
 user if it has not been used in some period of time.
 B) Losing control of your own domain name whether that be via someone
 stealing it or just that you don't want to have to pay for it  
 forever.

 Have we made a decision as to if we're looking for a solution to  
 solve
 both of these problems, only A, or only B?

 --David
 ___
 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: The CanonicalID Approach

2007-06-08 Thread Recordon, David
Not really trying to avoid the canonical ID having an OpenID service
listed, just figured not listing one would make the example simpler
though as you point out you certainly can have one.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Friday, June 08, 2007 1:42 PM
Cc: specs@openid.net
Subject: Re: The CanonicalID Approach

Josh Hoyt wrote:
 On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote:
 What I'd like to markup is that my three reassignable identifiers so
 that they all use my LiveJournal userid URL as the persistent
 identifier.  It should be noted that also marking them as synonyms to
 each other follows the same sort of process using the Ref/ tag in
my
 various XRDS files.
 
 -1 on requiring a whole extra round of discovery for every sign in. If
 you can come up with a way to verify that (a) the identifier in
 question points to the canonical ID and (b) the canonical ID has the
 appropriate information in it without doing twice the discovery, I'd
 like to hear it.
 

I figure that you could potentially use the same mechanism as delegation

to avoid the extra discovery iteration.

The problem, as with delegation, is that you need to duplicate the 
endpoint URL in the source identifier's XRDS document. The canonical 
identifier must also support OpenID, which I believe is something they 
were trying to avoid.

___
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: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
I don't see how it requires a centralized registry, if I choose to trust
that LiveJournal, or some ugly URL from AOL, etc will never go away then
that is my choice.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Friday, June 08, 2007 4:08 PM
To: Drummond Reed
Cc: specs@openid.net
Subject: Re: Do We Agree on the Problem We're Trying to Solve?


On 8-Jun-07, at 4:00 PM, Drummond Reed wrote:


 Drummond Reed wrote:

 Multiple, redundant identifiers is what canonical ID mapping
 provides. It
 doesn't require a master directory; it's as distributed as OpenID
 itself,
 i.e., it simply provides a way to map a reassignable URL or XRI to a
 persistent URL or XRI.

 Dick Hardt wrote:

 The persistent URL or XRI *is* a master directory. What do you do
 when the persistent identifier is compromised, goes out of  
 business ...

 That is problem B.

 Canonical IDs do not solve B.

 I completely agree that B is a hard problem. However Canonical IDs  
 solve B
 if the identifier authority for the Canonical ID follows business and
 operational practices intended to solve B.

And I think there is a solution that does not require a single,  
central registry.

One of the other issues with the registry is it is challenging to  
provide directed identities.

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


The CanonicalID Approach

2007-06-07 Thread Recordon, David
So sitting up here in Seattle with Drummond and we're chatting about the
Canonical ID approach to the identifier recycling and losing
problem.  What I describe below is an example which shows four
identifiers that I use daily, one of them being persistent and that I
know will never be reassigned.

http://daveman692.livejournal.com - reassignable
http://www.livejournal.com/userinfo.bml?userid=1356357 - persistent
http://www.davidrecordon.com - do I want to own it forever?
http://openid.aol.com/daveman692 - reassignable

What I'd like to markup is that my three reassignable identifiers so
that they all use my LiveJournal userid URL as the persistent
identifier.  It should be noted that also marking them as synonyms to
each other follows the same sort of process using the Ref/ tag in my
various XRDS files.

It should also be noted that the identifier you're using as your
persistent identifier must allow you to add references back to your
other identifiers.  While this certainly is a specialized feature, we
envision that OpenID Providers will create a persistence service both
guaranteeing the URL will not be reassigned as well as providing means
to add additional references.  Many of the existing i-brokers already do
this by using OpenID to prove you control the references that you're
adding.  You could also, don't shudder too hard Dick :), use an i-number
as your persistent identifier via this method though on the flip-side
could also use a fragment if that is the approach someone would like to
take.

The nice thing is that this method is extremely flexible in terms of
what you use as your persistent identifier in different cases.  I fully
guarantee I haven't done a great job of explaining all of this, but
hopefully the main point gets across.

--David (and Drummond)

http://daveman692.livejournal.com
XRDS
  XRD
Service
  URIhttp://www.livejournal.com/openid/server.bml/URI
  Typehttp://openid.net/signon/1.0/Type
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://www.davidrecordon.com
XRDS
  XRD
Service
  URIhttps://pip.verisignlabs.com/openid/server/URI
  Typehttp://specs.openid.net/auth/2.0/signon/Type
  LocalIDhttps://recordond.pip.verisignlabs.com/LocalID
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://openid.aol.com/daveman692
XRDS
  XRD
Service
  URIhttps://api.screenname.aol.com/auth/openidServer/URI
  Typehttp://openid.net/signon/1.0/Type
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://www.livejournal.com/userinfo.bml?userid=1356357
XRDS
  XRD
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
Refhttp://www.davidrecordon.com/Ref
Refhttp://daveman692.livejournal.com/Ref
Refhttp://openid.aol.com/daveman692/Ref
  /XRD
/XRDS
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


The WordPress User Problem (WAS: RE: Specifying identifier recycling)

2007-06-05 Thread Recordon, David
I think the largest concern I have with fragments, or really any
pair-wise shared secret which can't be renegotiated, is that while it
solves issues for the large service providers it actually inhibits
OpenID within the grassroots community.

Imagine if I install WordPress (or insert other app here) on
https://davidrecordon.com and check the Use fragments to protect my
OpenID box.  A few months later I decide to remove WordPress, or an
upgrade blows away my OpenID extension data, or I'm using an extension
which stores the fragments in /tmp/ and they get blown away.  I now no
longer have access to my accounts on all the relying parties I've
visited.  Now what do I do?

We can't count on each RP implementing an account recovery mechanism;
remember OpenID outsources account management so you can focus on
building you application.  I can't call up my service provider and ask
them to fix it, since well I was using my own provider.  I could try to
call up my webhost and see if they can restore from a backup, but I'd
guess by the time I realize what that check box in my WordPress
extension settings did there may not even be backups anymore.  In the
end, I'd be extremely frustrated that OpenID didn't work for me  and I'd
write a really obnoxious blog post about how much OpenID sucks.

So while we solve one aspect of the recycling problem, we end up
creating a larger problem from the opposite side of the equation.  I'm
certainly not arguing that we shouldn't solve this problem, nor that
participation from large providers isn't vital, but would hate to see us
create a problem for all of the people out there that have really helped
gain OpenID traction.

I don't want to say that I have the answers here, since I don't think I
do.  I do however see the following possible solutions:
1) The core specification only talks about fragments in relation to
Relying Parties, to the extent that they should be stripped from display
though used as a unique key.  We do however need to address how a RP
should handle display and account management differences when a fragment
changes.  I'm guessing it is unreasonable to expect every instance of
https://davidrecordon.com to be replaced with
https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
to mention that the fragment *must* remain private between the OP and RP
to be effective).  An extension is then written describing fragment
usage from the OP perspective with huge warnings about how it should
only be used by large service providers who know what they're doing.

2) We use a centralized canonical id approach like i-numbers.
Basically somebody issues unique and never reassigned ids.

3) We use a distributed canonical id approach.  Providers issue an
ugly non-reassignable URL which points at the pretty one and vice-versa.
Thus https://davidrecordon.com says its canonical is
https://12jbd9210.pip.verisignlabs.com which in turn says it is
https://davidrecordon.com.  We could even kill two birds with one stone
and use link rel='me' / to do this and setup an easy way to create
identifier equality.

4) We use public/private key pairs, though this has the traditional
private key revocation issues.

I think my preference is #3, though I'm sure it has its own issues.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 03, 2007 6:35 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling


On 3-Jun-07, at 1:46 AM, Recordon, David wrote:

 I thought at IIW we agreed that if we could come to quick consensus  
 on a
 way to resolve the problem it would be a part of 2.0, otherwise it  
 would
 not...

Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on  
how to solve this issue. But the issue was deemed important enough to  
be one of the only two on the 2.0 agenda.

 As concerns with the fragment proposal have been raised, which had the
 most agreement at IIW, it seems we no longer have consensus.

I haven't seen many actually; checking this thread for what can count  
as concerns reveals only:
a) Josh's initial email
b) Johannes' +1 to not adopting a solution that doesn't actually work
c) David acknowledging the concerns

This doesn't seem to me to carry enough weight to veto the fragment  
proposal, especially when a) has been / can still be addressed, and  
the fragment proposal made sense to a dozen people at that meeting.

 As seen in
 this thread, there are a wide variety of opinions as to how to resolve
 this concern.  I thus think merely picking one for the sake of putting
 something into 2.0 would be misguided.

True, there have been a few (I definitely wouldn't call it a wide  
variety) possible solutions mentioned, but none very well defined,  
and none had the support of 10+ people like the fragment did.

I have argued that it will have to be core (whether 2.0 or 3.0). I  
guess we should ask ourselves then if we really want this addressed  
in 2.0

RE: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Recordon, David
Since it seems no one has replied yet, I'd agree that this would make
implementations easier.  Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Monday, April 30, 2007 12:48 PM
To: specs@openid.net
Subject: Auth 2.0 Extensions: Namespace Prefixes


As currently defined, an extension has a global namespace URI as well as

a request-local alias/prefix. For an extension with the namespace 
http://example.com/blah that has a field foo, the following fields are

to be sent:

 openid.ns.blah=http://example.com/blah
 openid.blah.foo=bar

It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:
 openid.extensions=blah,sreg,ax

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each
one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the key part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.




[1] I'm looking at you, PHP.

___
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: The WordPress User Problem (WAS: RE: Specifying identifier recycling)

2007-06-05 Thread Recordon, David
At that point I'd be concerned as to solving the big OP issue while
not solving the lost domain issue when some of the proposals could
possible solve both.  This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another ugly URL
which points back at the pretty one.  I know I need to write this up
more...

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 05, 2007 3:18 PM
To: Recordon, David
Cc: Josh Hoyt; Johannes Ernst; OpenID specs list
Subject: Re: The WordPress User Problem (WAS: RE: Specifying
identifier recycling)

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
 The relying parties SHOULD make the fragment available to software 
 agents, at least, so that it's possible to compare identifiers across 
 sites. If the fragment is never available, then there is confusion 
 about which user of an identifier is responsible for content that has 
 been posted. One use case where software agents having access to the 
 fragment is particularly important is if the identifier is used for 
 access control, and the access control list is retrieved from off-site

 (e.g. from a social networking site).

 The implementation that seems most sane is for places that display the

 identifier for human reading look like:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

 so that the software agent would see the fragment, but the user 
 wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

 I thought the fragment was to be secret so that for the case of using 
 a personal domain you don't have to own joshhoyt.com forever.  Rather 
 as long as your fragments are secret, someone else can buy 
 joshhoyt.com and not be you.  If this is no longer a requirement then 
 it certainly changes the game, though also doesn't solve one of the 
 other aspects of identifier recycling.

I thought so too, but I believe Josh is right - the lost domain  
cell with an X in it (for URL + public fragment) supports Josh's
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually simpler
to address just the identifier recycling for big OPs, where loosing the
domain is not an issue.


Johnny

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


RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread Recordon, David
Yes, I think this would be worthwhile to write-up.

--David 

-Original Message-
From: =drummond.reed [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 05, 2007 4:55 PM
To: Recordon, David; 'Johnny Bufu'
Cc: 'OpenID specs list'
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence is the main use case for it).

I'm happy to help with the writeup -- I've already spent a
not-insignificant portion of my lifespan dealing with this issue ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Tuesday, June 05, 2007 3:50 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

At that point I'd be concerned as to solving the big OP issue while
not solving the lost domain issue when some of the proposals could
possible solve both.  This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another ugly URL
which points back at the pretty one.  I know I need to write this up
more...

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 05, 2007 3:18 PM
To: Recordon, David
Cc: Josh Hoyt; Johannes Ernst; OpenID specs list
Subject: Re: The WordPress User Problem (WAS: RE: Specifying
identifier recycling)

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
 The relying parties SHOULD make the fragment available to software 
 agents, at least, so that it's possible to compare identifiers across 
 sites. If the fragment is never available, then there is confusion 
 about which user of an identifier is responsible for content that has 
 been posted. One use case where software agents having access to the 
 fragment is particularly important is if the identifier is used for 
 access control, and the access control list is retrieved from off-site

 (e.g. from a social networking site).

 The implementation that seems most sane is for places that display the

 identifier for human reading look like:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

 so that the software agent would see the fragment, but the user 
 wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

 I thought the fragment was to be secret so that for the case of using 
 a personal domain you don't have to own joshhoyt.com forever.  Rather 
 as long as your fragments are secret, someone else can buy 
 joshhoyt.com and not be you.  If this is no longer a requirement then 
 it certainly changes the game, though also doesn't solve one of the 
 other aspects of identifier recycling.

I thought so too, but I believe Josh is right - the lost domain  
cell with an X in it (for URL + public fragment) supports Josh's
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually simpler
to address just the identifier recycling for big OPs, where loosing the
domain is not an issue.


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: Specifying identifier recycling

2007-06-03 Thread Recordon, David
I thought at IIW we agreed that if we could come to quick consensus on a
way to resolve the problem it would be a part of 2.0, otherwise it would
not...

As concerns with the fragment proposal have been raised, which had the
most agreement at IIW, it seems we no longer have consensus.  As seen in
this thread, there are a wide variety of opinions as to how to resolve
this concern.  I thus think merely picking one for the sake of putting
something into 2.0 would be misguided.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 02, 2007 10:12 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling


On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
 I'd like to see this written as an
 extension so that if the first approach doesn't work, the Auth spec
 itself doesn't have to be reverted.  Rather we can finish 2.0 and try
 implementing different approaches before deciding on the final way to
 solve this problem.

I thought we had agreed at IIW (for good reason) to address this in  
2.0. Other than the actual solution not being 100% clear, has  
anything changed?

Arguments for not putting it into an extension:
- users of provider's X who employs 'identifier recycling extension'  
would not be able to log into RP Y who doesn't understand the extension
- it's likely that whatever solution we come up with affects the  
discovery / verification processes, in which case it couldn't be  
pushed to an extension (we're trying to patch something about the  
_identifier_ itself, which is the center of each openid transaction).


Also, I believe the fragment approach can actually work, as detailed  
here:

http://openid.net/pipermail/specs/2007-May/001767.html

I haven't seen any replies to this, so would appreciate if others  
would go through the proposed changes and see if they all makes sense  
of I've overlooked something.


Thanks,
Johnny

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


RE: Specifying identifier recycling

2007-06-02 Thread Recordon, David
 Overall, I'm not sure we are ready in this community to pick one
 alternative over another as the standards. I have my views,
 (many) others have (many) others -- and I don't think that any
 of this has to be in an Authentication 1.x (x1) or 2.0 spec,
 whatever it will be. This seems like a clean add-on.

I also agree with Johannes here.  I'd like to see this written as an
extension so that if the first approach doesn't work, the Auth spec
itself doesn't have to be reverted.  Rather we can finish 2.0 and try
implementing different approaches before deciding on the final way to
solve this problem.

SREG shows how 1.1 can be extended, 2.0 clarifies this mechanism and
makes it more robust, let's take advantage of it especially given that
not all providers require this feature (whether via fragments or public
keys).

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Wednesday, May 30, 2007 10:30 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling

If we cannot assume that nobody manages to obtain a secret they  
should not have gotten in the first place, then OpenID as it stands  
is rather useless as we cannot trust its  authentication scheme.

Note that the surface through which the D-H shared secret can escape  
is about twice as large as the surface through which a private key  
can escape -- because an RP does not have access to the private key.  
In other words, if I was an attacker, I'd go after a lot of things  
first before I'd try to obtain a private key.

Note also that public keys would make rather good i-numbers -- for  
those who would like to, they can ignore that they are public keys  
and do i-number-based verification only, because they are simply  
numbers. For those who don't care about i-numbers, they use their  
public key aspects. Win-win, perhaps?

There is also the case -- which Stefan Brands would undoubtedly bring  
up if he was on this list -- that the IdP may be hostile, or may  
become hostile. (think of, say, a large OpenID provider going out of  
business, and being bought out by spammer.com -- or just the domain  
name whose registration lapsed) A scheme that is public key based is  
inherently more resilient towards this than one that is not. You  
certainly don't want to trust spammer.com to honor whatever  
conventions the previous owner of the domain put in place to  
disambiguate their users.

--

Overall, I'm not sure we are ready in this community to pick one  
alternative over another as the standards. I have my views, (many)  
others have (many) others -- and I don't think that any of this has  
to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will  
be. This seems like a clean add-on.



On May 30, 2007, at 22:01, Drummond Reed wrote:

 Johannes:

 What about the point Dick posted earlier in this thread, that the  
 problem
 with using a public key is if the private key gets compromised?  
 Persistent
 identifiers need to persist independent of any attribute changing  
 or being
 revoked.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf
 Of Johannes Ernst
 Sent: Wednesday, May 30, 2007 9:54 PM
 To: OpenID specs list
 Subject: Re: Specifying identifier recycling


 On May 30, 2007, at 21:02, Johnny Bufu wrote:

 ...The bottom line is
 that it can't be done easily - a mechanism similar to XRI's canonical
 ID verification would have to be employed, to confirm that the i-
 number actually 'belongs' to the URL on which discovery was
 initiated. (Otherwise anyone could put any i-number in their URL-
 based XRDS files.)

 Public keys ... public keys ... with the added benefit that no
 centralized or trusted verification service needs to be employed
 whatsoever ...




 Johannes Ernst
 NetMesh Inc.



 ___
 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: Specifying identifier recycling

2007-06-01 Thread Recordon, David
Just for reference, this draft spec takes a look at key discovery for
OpenID URLs.
http://openid.net/specs/openid-service-key-discovery-1_0-01.html

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Friday, June 01, 2007 1:40 PM
To: Nat Sakimura
Cc: 'OpenID specs list'
Subject: Re: Specifying identifier recycling


On May 31, 2007, at 18:41, Nat Sakimura wrote:

 Public key idea is somewhat attractive to me, but there are some  
 issues that
 comes up in my mind as well.

Bring them on ;-)

 1) Storing many users' private key on the server in decryptable  
 format is
 not very safe.

 In your proposal, it looks like that OP is going to hold the  
 private key for
 each user in decryptable format. Considering that most large scale  
 privacy
 leakage happens at the server side, I have got a feeling that such  
 thing
 like private key in a shared location.

How would this be less safe than storing many shared secrets (per  
OpenID Auth) in decryptable format, or clear-text (more likely) on  
the server?

Note that these private keys would not be general-purpose private  
keys, but only for the specific purpose we are discussing here.

Also, I suspect that the use of these keys would be fairly infrequent  
compared to other operations, so conceivably one could add additional  
safeguards of various kinds if that was needed.

 2) It may mean a high cost operation for OPs.

 If we do this, it makes OP operation very high cost because to make  
 the
 service safe, it would require a lot of measures. (NRI is providing  
 similar
 kind of service but it indeed is very high cost operation.)

 Nice thing about i-number is that it has no value like public key  
 except for
 its resolvability. Even if it leaks, that's kind of ok so  
 operational risk
 is low.

This comparison does not work very well for me. However: I don't know  
the details of how to avoid impersonation via i-numbers (in case of  
key pairs, it would be private key leaks and is reused by attacker  
-- what would be the equivalent for i-numbers?), but I suspect there  
are some measures that prevent attackers from impersonation by using  
somebody else's i-number? If so, aren't they similarly susceptible to  
attack?

 Actually, these private key pain may be eased by IBE (Identity Based
 Encryption) but I need some more time to contemplate on it.

I had somebody else mention this to me -- I wonder whether anybody  
could put together an actual proposal.

 3) Since OPs has an access to the users' private key, they may  
 recycle them
 as well.

 IMHO, recycling is operational problem as well as a technical one.
 i-number from a certified i-broker is somewhat trustable on the  
 account of
 no recycling because of this operational restriction. Could there be
 operational restriction similart to that for general OPs as well?

There could, and -- I suspect -- in the longer term there probably  
will, but the whole point about a decentralized system like OpenID is  
to keep the playing field level without a central entity in the  
middle for the maximum length of time and scope possible.

In any case, I think we should use the approach to use  
(decentralized) technology to the maximum extent possible, and only  
add operational requirements when unavoidable. (And I know that many  
people on this list would scream bloody murder if anybody seriously  
proposed such a centralized requirement for OpenID usage ...)  
Personally I would feel we didn't think hard enough on this  
particular problem if the solution to this problem required us to use  
centralization of some kind.


 =nat





 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
 Sent: Thursday, May 31, 2007 2:30 PM
 To: OpenID specs list
 Subject: Re: Specifying identifier recycling

 If we cannot assume that nobody manages to obtain a secret they
 should not have gotten in the first place, then OpenID as it stands
 is rather useless as we cannot trust its  authentication scheme.

 Note that the surface through which the D-H shared secret can escape
 is about twice as large as the surface through which a private key
 can escape -- because an RP does not have access to the private key.
 In other words, if I was an attacker, I'd go after a lot of things
 first before I'd try to obtain a private key.

 Note also that public keys would make rather good i-numbers -- for
 those who would like to, they can ignore that they are public keys
 and do i-number-based verification only, because they are simply
 numbers. For those who don't care about i-numbers, they use their
 public key aspects. Win-win, perhaps?

 There is also the case -- which Stefan Brands would
 undoubtedly bring
 up if he was on this list -- that the IdP may be hostile, or may
 become hostile. (think of, say, a large OpenID provider going out of
 business, and being bought out by spammer.com -- or just the 

RE: Review of Yadis section in XRI Resolution 2.0 WD11

2007-05-31 Thread Recordon, David
Hi Drummond,
I'd recommend adding a section which pulls together the HEAD and GET
methods and describes how'd they be used in conjunction.  Also
explicitly pointing out that a URL hosting a XRDS document only is
required to implement one or more of the discovery mechanisms whereas a
service requesting XRDS documents must implement all of the different
methods.

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Drummond Reed
Sent: Wednesday, May 30, 2007 10:45 PM
To: 'OpenID specs list'
Subject: Review of Yadis section in XRI Resolution 2.0 WD11

As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and
vote on the XRI Resolution 2.0 spec (which has been at the Working Draft
10
stage during the entire evolution of OpenID Authentication 2.0) so it
can be
referenced by OpenID Authentication 2.0 when it goes final.

To that end, the first editor's draft of Working Draft 11 has been
posted
[1]. It's not quite content complete (all major changes have been
incorporated; we're now working on the smaller stuff), so we're not
asking
folks to review the whole thing yet (many OpenID folks think it's too
long
anyway ;-).

However it would be great to get feedback on the new section 8 that
incorporates the Yadis protocol. Per discussions with the OpenID editors
last fall, the XRI TC is including this in the XRI Resolution spec so
everything about XRDS documents and their discovery is referenceable in
an
open public OASIS spec, even if only URLs and no XRIs are involved.

To make this new section easy to review, we've put it on the XRI TC wiki
at:

http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris


It's pretty short and sweet, mostly because XRDS documents and their
context
and usage are defined elsewhere in the spec. So this section just
defines
the URL-based discovery protocol, which is the meat of the Yadis 1.0
spec.
The wording has been restructured slightly to fit the OASIS spec format,
however the only normative change was to make the recommendation to
include
the application/xrds+xml Accept header in the HEAD or GET request a
SHOULD
instead of a MAY. The XRI TC felt this was justified to encourage
efficiency
-- feel free to push back if you think that's the wrong call.

Since only XRI TC members can write to the wiki (due to OASIS IPR
rules),
please post any feedback here on the specs list and we'll reflect it on
the
wiki page as quickly as we can (I myself will be offline in meetings
tomorrow but back online tomorrow night).

Thanks,

=Drummond 

[1]
http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v
2.0-
wd-11-ed-01.doc 

___
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: Realm spoofing spec patch

2007-05-24 Thread Recordon, David
Hey Josh,
Thanks for writing this up!

I'm a bit confused by the number of SHOULDs in this patch.

+Relying Parties SHOULD use the Yadis protocol to publish their
+valid return_to URLs. The relying party MAY publish this
+information at any URL, and SHOULD publish it under the realm
+so that providers can verify return_to URLs.

+OpenID providers SHOULD verify that the return_to URL
+specified in the request is an OpenID relying party
+endpoint.

+If verification is attempted and fails, the provider
+SHOULD NOT send a positive assertion to that return_to
+URL. 

It seems that this methodology only works if either:
 1) Every site (RP or proxy) publishes their return_to endpoints or that
they don't have any.
 2) An OP refuses to let the user login to a RP which doesn't publish
their return_to endpoint.

I'm unconvinced that either of those situations will actually become
prevalent and thus worried about the effectiveness of this methodology.

Using the same example from IIW, I am logging into
http://evilrp.com/return_to which is proxying itself through
http://www.google.com/translate/.  If my OP were to prompt me, We're
unable to verify the site
(http://www.google.com/translate/?http://evilrp.com/return_to) you're
logging into, you should use caution when proceeding I'm unsure how
many users would actually not proceed, or rather see google.com and
decide it is alright.

I guess since we're unable to fully resolve this issue from a technical
perspective, and no I don't have a better technical solution, I'm
wondering if this should actually be an extension to the core protocol
versus seeming like a resolution to the problem when it really doesn't
completely solve it.  In some senses I see this as a larger problem
around trust of Relying Parties.  

--David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, May 24, 2007 4:19 PM
To: OpenID specs list
Subject: Realm spoofing spec patch

Hello,

I've added a section to the specification[1] about performing
verification on the realm to avoid realm spoofing. In short, realm
spoofing is the problem of exploiting a bug on a site that a user would
trust to trick them into sending their information to a site that they
would not trust. This is very similar to many phishing attacks. The
difference between this type of attack and a standard phishing attack is
that the user will (usually) only see the realm, and the realm may
actually be trusted, so even an educated user who's paying attention may
be vulnerable.

There are also (minor) changes to the section on discovering relying
parties[2].

The fix that is described is for the relying party to provide a
whitelist of URL patterns that should be usable as return_to URLs.
Relying parties should be as restrictive as possible when specifying
return_to URLs.

This is the fix that was discussed at the Internet Identity Workshop, by
all of the spec editors and several prominent members of the OpenID
community. Please review the additions. If you'd like to see the
specific changes, you can look at the diffs in revision control[3].

Josh


1.
http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-
327.html#return_to_verification
2.
http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-
327.html#return_to_verification
3.
http://openid.net/svn/listing.php?repname=specificationspath=rev=326;
sc=1
___
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: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-18 Thread Recordon, David
Please no talk of OpenID 3!  If anything, 2.1 or the next version. :)

Thanks,
--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, May 17, 2007 2:05 PM
To: Alaric Dailey
Cc: OpenID specs list
Subject: Re: Final outstanding issues with the OpenID
2.0Authenticationspecification

On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote:
 I hate to be a PITA but these issues were brought up a while ago by 
 Eddy Nigg and Myself.

I understand, but at that time, as now, I was trying to get the spec to
be finished. We've been in something of an informal feature-freeze for a
while. Perhaps we should have explicit feature-freezes.

I'd suggest starting an OpenID 3 thread to talk about the features that
you want to add. That way, you can start trying to convince people that
your features should go in without having to battle with people like me
who just want to have a stable spec release with the improvements that
we already have.

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


RE: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-18 Thread Recordon, David
Hey Dmitry,
When using Yadis you're able to advertise if you're speaking OpenID 1.1
or 2.0 and thus the RP know which version of the protocol the request
should be made in.  When using HTML-Based Discovery this is not possible
unless the attributes are renamed or a third version tag is added
which was not the preferred option.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dmitry Shechtman
Sent: Friday, May 18, 2007 1:00 AM
To: 'Josh Hoyt'; 'OpenID specs list'
Subject: RE: Final outstanding issues with the OpenID
2.0Authenticationspecification

7.3.3. HTML-Based Discovery

A LINK tag MUST be included with attributes rel set to
openid2.provider
and href set to an OP Endpoint URL

A LINK tag MAY be included with attributes rel set to
openid2.local_id
and href set to the end user's OP-Local Identifier


Could somebody please enlighten me as to what's wrong with leaving those
as openid.server and openid.delegate respectfully (i.e.
backward-compatible)?


Regards,
Dmitry
=damnian

___
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: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-18 Thread Recordon, David
Hey Don,
Certainly not alone, though I think what we really need to dig into is
if the spec is actually more complex from a feature perspective or
because it is much more verbose and adds clarity over 1.1.  Splitting
discovery into a separate spec I think will also help in the document
being less intimidating.  This is certainly an important issue though,
OpenID has largely been successful because of how simple OpenID 1.1 +
Yadis + SREG is compared to the value provided.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Don MacAskill
Sent: Friday, May 18, 2007 7:49 AM
To: OpenID specs list
Subject: Re: RFC: Final outstanding issues with the OpenID 2.0
Authenticationspecification


Josh Hoyt wrote:
 If these four issues are resolved, can we call the OpenID 2.0 
 Authentication specification done? Speak up if you have any other 
 show-stoppers.

 Josh
 

I hate to speak up last minute, but I was at a few tech conferences in
the past month or two, and spoke with lots of passionate OpenID
proponents.  There was a common thread among our discussions:  OpenID
2.0 seems to be getting massively more complex without a clear reason to
do so.  One of the best things about OpenID 1.1 is how easy and simple
it is to write for.

My company, SmugMug, is an OpenID provider for hundreds of thousands of
high value paying accounts, and will shortly be a consumer as well. 
I'll freely admit that I haven't fully digested 2.0's pre-spec, but at
least part of that reason is it looks like it adds a lot more
complexity.  I can honestly say that if I had seen it as a spec, rather
than 1.1, I would have certainly put off implementation, possibly
indefinitely.

As a relative newcomer to the OpenID community, I realize this may have
been debated endlessly already, and I may just be shouted down.  I'm a
n00b, I get that.  But are we really sure that a much more complex spec
is in the best interests of the community?

Or am I alone here?

Thanks,

Don
___
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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-18 Thread Recordon, David
Hi Dmitry,
I don't think the solution is to simple denounce OpenID 2.0, but that
will rather only make it worse.  Rather I'd invite you to continue these
productive conversations to see if the issues can be resolved.  I think
it would be unfortunate for anyone to just give up.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dmitry Shechtman
Sent: Friday, May 18, 2007 8:09 AM
To: 'Don MacAskill'; 'OpenID specs list'
Subject: RE: RFC: Final outstanding issues with the OpenID
2.0Authenticationspecification

 As a relative newcomer to the OpenID community, I realize this may 
 have been debated endlessly already, and I may just be shouted down.

It definitely has been debated endlessly.

 Or am I alone here?

No, you aren't. There are many who agree with this entirely, some of
whom have expressed their opinion on the various OpenID lists, but at no
avail.

My suggestion at this point would be to simply denounce OpenID 2.0.


Regards,
Dmitry
=damnian

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


Wiki Login Fixed

2007-05-01 Thread Recordon, David
Thanks to Jonathan from JanRain, you can now login to the wiki again!

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


RE: axschema.org instead of openid.net

2007-04-20 Thread Recordon, David
Sounds good!

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Friday, April 20, 2007 12:46 PM
To: OpenID specs list
Subject: axschema.org instead of openid.net

Thanks everyone for feedback on using schema.openid.net. Here are my
conclusions:

1) A number of people would like to be using a web oriented schema right
away and don't want to wait for other groups to create the schema.

2) A number of people are allergic to the openid.net domain being used
for things that are not openid.net protocol specific.

Sxip has acquired axschema.org (Attribute eXchange schema :-) and we
will host the site and a mail list as a service to the community and
operate it per http://openid.net/specs/openid-attribute-
types-1_0-02.html

If I don't hear from anyone that they don't like this idea, then we will
set this up next week.

-- 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: PROPOSAL schema.openid.net for AX (and other extensions)

2007-04-09 Thread Recordon, David
Hey Brian.
Just to clarify, I don't think there is disagreement that this should be 
discussed here.  Rather the question is if discussion should be around creating 
a new schema on openid.net or rather looking at using an exisiting one such as 
ldap.com that Mark posted about?  Ie, discussion location aside, do you believe 
the OpenID project should be creating a new schema of its own?

--David


 -Original Message-
From:   Brian Hernacki [mailto:[EMAIL PROTECTED]
Sent:   Monday, April 09, 2007 09:48 AM Pacific Standard Time
To: OpenID specs list
Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions)


On 4/6/07 6:07 PM, Dick Hardt [EMAIL PROTECTED] wrote:
 
 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.

For what it's worth, as an implementer...

I think it makes sense to come to agreement within the OpenID community and
get something working first. While I appreciate the issues involved with
having multiple protocols and attribute definitions, I worry that if this
becomes coupled to other efforts it would cause delays. Better to at least
come to that table with a sound version of what we think works.

Given that, discussing it here (openid.net) seems natural.

--brian

___
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)

2007-04-09 Thread Recordon, David
Yes, I agree an upgrade path from SREG is needed.  We could however do
something as simple as
http://openid.net/specs/openid-simple-registration-extension-1_0.html#ni
ckname for the existing SREG fields.

For new fields, is there a reason we can't use the ldap.com URLs Mark
posted as a starting point?  I know Dick said they didn't cover all the
needed attributes, but would it be good enough to start with and then
expand from there possibly on schema.openid.net?  Dick, do you have a
list of attributes you see as needed for the first implementations of AX
(I couldn't find one in the current AX specs though I fully admit I may
be looking in the wrong place)?

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of James Walker
Sent: Monday, April 09, 2007 1:10 PM
To: Martin Atkins
Cc: OpenID specs list
Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions)

On 4/9/07 3:55 PM, Martin Atkins wrote:
 James Walker wrote:
 As an implementor - there would be extremely positive benefits from 
 having a base set of attributes defined and available @ 
 schema.openid.net . I agree that the people most interested right now

 are the OpenID community  implementors and it makes sense (to me) 
 for openid.net to offer something - even just as a 'getting started
point'.

 [snip]
 What we need now (from my point of view) is a base set that we can 
 work against to build momentum behind AX (building on the momentum 
 already behind OpenID).

 
 If our goal is to not reinvent the wheel, then let's just identify 
 some AX mappings for the existing SREG fields, thus killing two birds 
 with one stone: people migrating from SREG get some fields that offer 
 one-to-one mappings, and these fields can be defined just by 
 referencing the existing SREG specification so we avoid having to
define anything.
 
 SREG seems to be working well in the common case, so it seems like a 
 reasonable place to start.

I agree it's an excellent place to start - upgrade path + as you point
out it's working well in several cases today.

--
James Walker :: http://walkah.net/ :: xmpp:[EMAIL PROTECTED]
___
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)

2007-04-09 Thread Recordon, David
Is there a list anywhere?  I didn't find one in the documents and I think this 
list would benefit everyone in the conversation.  I'm just curious as to the 
fields you're expecting an OP to implement.

--David


 -Original Message-
From:   Dick Hardt [mailto:[EMAIL PROTECTED]
Sent:   Monday, April 09, 2007 07:12 PM Pacific Standard Time
To: Recordon, David
Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list
Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions)


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

 For new fields, is there a reason we can't use the ldap.com URLs Mark
 posted as a starting point?  I know Dick said they didn't cover all  
 the
 needed attributes, but would it be good enough to start with and then
 expand from there possibly on schema.openid.net?  Dick, do you have a
 list of attributes you see as needed for the first implementations  
 of AX
 (I couldn't find one in the current AX specs though I fully admit I  
 may
 be looking in the wrong place)?

There are many, many attributes that we are using in AX that are not  
in LDAP, or don't have the granularity.

-- Dick


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


Re: SREG namespace URI rollback

2007-04-08 Thread Recordon, David
I'm fine with keeping it 1.0 as Josh proposed.

--David


 -Original Message-
From:   Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent:   Saturday, April 07, 2007 09:38 PM Pacific Standard Time
To: Recordon, David
Cc: Josh Hoyt; OpenID specs list
Subject:Re: SREG namespace URI rollback


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

 Sure, though I think there has also been a desire to do a bit of an

Are we in agreement then (about 1.0 and 1.1 sharing the same type URI)?

I went ahead and implemented SREG in openid4java, and exposed it in  
such a way that the users won't have to know about all these v1.0 /  
1.1 details. But in order for that to work and my implementation to  
be compliant, the type URI of SREG 1.1 needs to change as proposed by  
Josh in the next (final?) draft.

Thanks,
Johnny

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


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

2007-04-06 Thread 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
specs@openid.net
http://openid.net/mailman

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

2007-04-06 Thread 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.org/ws/2005/05/identity/claims/givenname

 This URL could be used. To date they have

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

2007-04-05 Thread Recordon, David
I guess I don't see why blaming the ID Schemas project for not much
happening is a good excuse for not doing it there.  People who care will
either have to drive this work within the OpenID project or the ID
Schemas project; I fail to see how the effort required in each differs
greatly.  In some senses, I think if people gather as part of the ID
Schemas project and try to move this work forward, it will actually be
more successful than trying to do it here.

Nothing done by OpenID in the past has intrinsically been easy which is
why I continue to think that something being hard is not a valid reason
to not do the right technical/social thing.  I know that these two
communities can work together, but the onus is on the OpenID AX side to
make this conversation successful and drive progress.

Cc'ing their list as well.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 05, 2007 8:00 AM
To: Drummond Reed
Cc: Recordon, David; 'Johnny Bufu'; 'OpenID specs list'
Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

Doing the work in the ID Schemas project  was a good idea 3 months ago
and 6 months ago. So far not much has happened there.

I agree that having several groups do the same thing is undesirable, but
we do need to get moving.
We need URIs for moving attributes today. We can wait for the metadata
[1] to get defined, and the members of the ID Schema group are the right
people for that.[2]

While it is desirable that there is only one definition of an attribute,
and some people may define the same attribute through lack of knowledge
of each other. The attribute meta data model proposed[1] allows for one
definition to reference another definition to consolidate attribute
definitions.

Additionally, getting everyone to agree on the syntax will be hard.  
The model allows different people to define attributes in different
ways. The market will decide then what works best through use.

btw: Currently there is no consistent, extensible, self describing
attribute schema system out there that I know of, or anyone in the ID
Schema Working group knows of.

We can start to define attributes in the openid.net namespace and then
reference more authorative URIs when they exist.

This would let the OpenID community define the immediately required
attributes for people to implement and deploy AX, which will likely
increase awareness

[1] http://openid.net/specs/identity-attribute-metadata-1_0-01.html

[2]  Of course we have all the issues of IPR etc. at the ID Schema
working group since it would be unclear what organization would be
managing that spec. Over here in the OpenID community we are working to
resolve that, so perhaps the ID Schema people could participate in a
list hosted at openid.net?

-- Dick

On 4-Apr-07, at 10:27 PM, Drummond Reed wrote:

 +1 to defining attribute identifier URIs/XRIs in the Identity  
 Commons ID
 Schemas project.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf
 Of Recordon, David
 Sent: Wednesday, April 04, 2007 1:16 PM
 To: Johnny Bufu
 Cc: OpenID specs list
 Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)

 Johnny,
 I see a lot of, at least my initial confusion, coming from there being
 multiple documents.  This is why I urge merging the transport and
 metadata since the reality is they currently are only being used with
 each other.  As the metadata document doesn't actually define a new
 format, rather references existing formats, I am unsure why it cannot
 just be a section in the transport document.  It is understood that  
 you
 must use the metadata format for the schema URLs in the transport, so
 the two documents really are coupled to begin with.

 I agree that you need to bootstrap a set of attributes for people  
 using
 AX.  As I have done so in the past, I'd encourage this work happen
 within the ID Schemas project (http://idschemas.idcommons.net/) versus
 defining First Name yet again for openid.net.  I have no problem with
 the spec listing a set of schema URLs, I just strongly feel that
 anything non-OpenID specific should be hosted and defined elsewhere
 since so many people have already done it.  I do understand the  
 need for
 the schema URL hosting the metadata document, which is why I am
 advocating this work be done as part of the ID Schemas project to
 provide this flexibility.

 --David

 -Original Message-
 From: Johnny Bufu [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 04, 2007 12:39 PM
 To: Recordon, David
 Cc: Dick Hardt; OpenID specs list
 Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)


 On 4-Apr-07, at 12:18 PM, Recordon, David wrote:
 One thing that I do think would be worthwhile in smoothing more of
 this SREG/AX confusion would be adding SREG support to Sxip's OpenID
 libraries.

 This is on the todo list, and judging by the interest showed by some
 contributors could

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

2007-04-05 Thread Recordon, David
 Actually it is describing a document format, and it could easily be
used
 by other groups as evidenced by references from people in the ID
Schemas
 group.
I agree that it could be, but is anyone?  I love shooting beyond the 80%
to get the remaining 20%, but if that is just a pipe dream then I have a
hard time seeing why the documents need to be separate and thus more
complex.  If however this format was defined within the ID Schemas
project, then that would be an easy argument as to why they should be
separate.

 We defined a set of attributes 6 months ago under schema.openid.net.
So Dick, this is part of my problem with AX.  Sxip has defined a set of
attributes and never gained consensus on this list that that is the
right thing to do.

See my other message a few minutes ago as to the rest of my thoughts.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 05, 2007 8:27 AM
To: Recordon, David
Cc: Johnny Bufu; OpenID specs list
Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)


On 4-Apr-07, at 1:16 PM, Recordon, David wrote:

 Johnny,
 I see a lot of, at least my initial confusion, coming from there being

 multiple documents.  This is why I urge merging the transport and 
 metadata since the reality is they currently are only being used with 
 each other.  As the metadata document doesn't actually define a new 
 format, rather references existing formats, I am unsure why it cannot 
 just be a section in the transport document.  It is understood that 
 you must use the metadata format for the schema URLs in the transport,

 so the two documents really are coupled to begin with.

Actually it is describing a document format, and it could easily be used
by other groups as evidenced by references from people in the ID Schemas
group.


 I agree that you need to bootstrap a set of attributes for people 
 using AX.  As I have done so in the past, I'd encourage this work 
 happen within the ID Schemas project (http://idschemas.idcommons.net/)

 versus defining First Name yet again for openid.net.  I have no 
 problem with the spec listing a set of schema URLs, I just strongly 
 feel that anything non-OpenID specific should be hosted and defined 
 elsewhere since so many people have already done it.  I do understand 
 the need for the schema URL hosting the metadata document, which is 
 why I am advocating this work be done as part of the ID Schemas 
 project to provide this flexibility.

see my response to Drummond ...

We defined a set of attributes 6 months ago under schema.openid.net.

I think we have let other groups have time to do something, I'd like to
get on with building and deploying stuff.

-- Dick


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


RE: SREG namespace URI rollback

2007-04-04 Thread Recordon, David
In some sense both, maybe it is just how the documents seem to be laid
out, it just doesn't seem as dead simple as SREG.  Maybe it is just
reworking the layout of
http://openid.net/specs/openid-attribute-exchange-1_0-04.html and
removing the document about policy versus technology
http://openid.net/specs/openid-attribute-types-1_0-02.html.

Can we also separate out all of the SAML stuff, as far as I can tell it
isn't up on the specs page but I think the discussions around these four
different documents without clearly being able to tell when people are
talking about what has been detrimental to the entire process.

I think I'd propose the following:
 - Remove http://openid.net/specs/openid-attribute-types-1_0-02.html (I
do not believe OpenID should define its own schema elements for things
like First Name which are not specific to OpenID, defining a URL for
an OpenID enabled URL for example I think would be fine on OpenID.net)
 - Merge http://openid.net/specs/identity-attribute-metadata-1_0-01.html
into http://openid.net/specs/openid-attribute-exchange-1_0-04.html.
 - Cleanup the newly merged
http://openid.net/specs/openid-attribute-exchange-1_0-04.html to be more
concise and list URLs for the existing SREG parameters.  This will thus
show an easy upgrade path between SREG and AX.

All through this process it is also important to discuss it on this list
and drive consensus with the community.  In some senses, I think parts
of my objections to AX are how it seems like it has just been shoved
down my throat over the past six months.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 03, 2007 10:00 PM
To: Recordon, David
Cc: Josh Hoyt; OpenID specs list
Subject: Re: SREG namespace URI rollback

I can see an OP thinking that AX is a big step, but have a hard time
seeing it to be that big for an RP (once there are libraries that
support AX) ... and it is really not that much more to do AX over SREG
for an RP.

Where you thinking OP or RP David?

-- Dick

On 3-Apr-07, at 12:17 PM, Recordon, David wrote:

 I see there being a gap between SREG and AX with nothing bridging it.
 IMHO, AX takes too large of a step for people to use it if they just 
 want a few more SREG fields.  I think we need something which does 
 nothing more than provide a way to extend SREG and that will solve the

 majority of problems today.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh

 Hoyt
 Sent: Monday, April 02, 2007 7:16 PM
 To: Recordon, David
 Cc: Johnny Bufu; OpenID specs list
 Subject: Re: SREG namespace URI rollback

 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



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


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

2007-04-04 Thread Recordon, David
Hey Johnny,
I agree that you're doing a good job especially with your pre-draft 5
review message.  Let's continue that way!  There have been things in the
past, not that you've done, which have certainly rubbed me the wrong way
about AX.  Does seem like we're all moving forward though with good
progress.

One thing that I do think would be worthwhile in smoothing more of this
SREG/AX confusion would be adding SREG support to Sxip's OpenID
libraries.

Any thoughts on spec consolidation and seperating policy from
technology?

--David 

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 04, 2007 12:09 PM
To: Recordon, David
Cc: Dick Hardt; OpenID specs list
Subject: Re: SREG namespace URI rollback

David,

On 4-Apr-07, at 11:43 AM, Recordon, David wrote:
  - Cleanup the newly merged
 http://openid.net/specs/openid-attribute-exchange-1_0-04.html to be 
 more concise and list URLs for the existing SREG parameters.  This 
 will thus show an easy upgrade path between SREG and AX.

I think this is a good idea - to add a note / paragraph outlining
clearly the upgrade path from SREG to AX.

 All through this process it is also important to discuss it on this 
 list and drive consensus with the community.  In some senses, I think 
 parts of my objections to AX are how it seems like it has just been 
 shoved down my throat over the past six months.

Not sure what *exactly* you mean with the above, but at least for the
least 3 months or so we've been trying to get the community involved
with AX, on the lists here:

http://openid.net/pipermail/specs/2007-January/001141.html
http://openid.net/pipermail/specs/2007-February/001283.html
http://openid.net/pipermail/specs/2007-March/001385.html

Is there something in particular about the way we handled this that
doesn't seem right to you? If yes - what exactly do you think should be
done differently?


Thanks,
Johnny

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


RE: Promoting OpenID

2007-04-03 Thread Recordon, David
People might be, though nothing real formal that I personally know of.
You volunteering? :P

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of McGovern, James F (HTSC, IT)
Sent: Monday, April 02, 2007 8:15 AM
To: specs@openid.net
Subject: Promoting OpenID

As an end-user to user-centric approaches, I have noticed an interesting
pattern. Microsoft does a wonderful job of selling Cardspace as a
solution to others who develop in Microsoft languages. Likewise, there
are tons of vendors that can offer solutions for large enterprises to
purchase but no one is promoting user-centric approaches to the vendors
us large enterprises do business with in terms of getting them to
embrace user-centric approaches within their own code base. Sure, we can
as consumers raise awareness, but I would like to understand thoughts on
other than procurement, how could we make this more pervasive?

Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM
spaces such that user-centric identity is built into their product?



*
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: SREG namespace URI rollback

2007-04-02 Thread 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: Proposal for Modularizing Auth 2.0 Discovery

2007-03-02 Thread Recordon, David
I agree.  I think it is great having a way for people to easily propose
new identifier formats and even use them within their own
implementations.  There does however need to be some sort of community
review process before new identifiers are added to OpenID in a public
fashion.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Friday, March 02, 2007 12:47 PM
To: specs@openid.net
Subject: Re: Proposal for Modularizing Auth 2.0 Discovery

While I'm strongly in favor of modularization from an architectural
perspective, is there a potential security problem here if multiple
protocols are developed to resolve the same kind of identifier?  
(because they could resolve to a different set of endpoints / services)

It appears to me that the only way this can work is that while we
modularize, we only let the same set of people who have defined some of
the plug-in documents define new plug-in documents how to do
discovery. The Yadis decentralized innovation model -- everybody define
the service types they like, they don't need to ask anybody -- may not
work here.

Or am I off-base?

Cheers,


Johannes.




Johannes Ernst
NetMesh Inc.


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


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
+1, I'm fully in support of this and actually have been wanting to do so
for quite a number of weeks now!

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 10:44 AM
To: specs@openid.net
Subject: Modularizing Auth 2.0 Discovery


Recently there has been talk about using alternative identifiers for
OpenID, such as email addresses and Jabber Identifiers. This has made it
obvious that the OpenID Authentication protocol doesn't care in the
slightest what the identifier is as long as service discovery can be
performed on it somehow.

Currently the Authentication 2.0 specification has language in various
places that constrains it to URIs with the schemes http, https and xri. 
For example, under Terminology the following definition is given for
Identifier:

 An Identifier is either a http or https URI, (commonly referred
 to as a URL within this document), or an XRI [XRI_Syntax_2.0].
 This document defines various kinds of Identifiers, designed for
 use in different contexts.

My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It
would just state that an identifier is a URI. Later in the spec, where
currently it enumerates a bunch of ways to do discovery, it'd just say
do discovery on the URI using an appropriate protocol. (or, indeed,
words to that effect.) It would also nominate a standard XRDS service
type URI to use during Yadis discovery.

Then we'd publish in parallel the following two ancillary
specifications:
 * OpenID Discovery for HTTP and HTTPS URIs
 * OpenID Discovery for XRI URIs.

Later, the OpenID community or a third party could publish a
specification OpenID Discovery for Email Addresses, but I don't think
we're really ready to go there right now.

The discovery protocols don't necessarily need to be XRDS-based, but if
they are they would presumably reference the standard service type URI
from the Auth spec so that future Auth versions can change this without
needing to re-publish the discovery specs.

This has the following benefits:

   * It gives others a clear, spec-approved mechanism to bolt-on support
for additional URI schemes.

   * It allows the Authentication specification to evolve separately
from the various discovery specifications, which are unlikely to need to
change very much from version-to-version.

   * It formalizes the separation between discovery and authentication,
giving library authors a clear plug-in point if they wish to support
modular discovery.

Presumably the OpenID Auth 2.0 spec would still retain a reference to
the HTTP and HTTPS discovery spec purely so that it can say that RPs
MUST support it regardless of what else they support.

-

All ancillary discovery specifications must, at minimum, define:

   * A pattern for recognizing and canonicalizing their own identifiers.

(For example, the XRI one would include a provision for checking for an
identifier which starts with a global context symbol, etc.)

   * A mechanism for returning the following information:
 - Either: (traditional identity case)
 * Canonical Claimed identifier (an i-number, for example)
 * User-supplied Display identifier (an i-name, for example)
 * OP endpoint URL
 * OP-local identifier (i.e. openid:Delegate as was)
 - Or: (directed identity case)
 * OP endpoint URL
 * Canonical OP identifier (for use in confirmation messages)

(And, of course, not all discovery mechanisms would necessarily support
directed identity.)


___
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: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
Well there already is the Yadis spec.  Maybe the Yadis spec remains
separate versus becoming part of the OASIS XRI Resolution document?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 11:59 AM
To: specs@openid.net
Subject: Re: Modularizing Auth 2.0 Discovery

Martin Atkins wrote:
 My proposal is that we make the core Auth 2.0 spec scheme-agnostic.

Attached is a version of the current spec draft 11 with large chunks of
the discovery/normalization stuff hacked out and replaced with generic
see other specifications text.

I think I may have deleted too much in that we've lost the detailed
rules for dealing with XRDS documents, which are probably going to be
referenced by most discovery specs and deserve to be in the core spec. 
See the TODO: markers for more info.

However, in doing this it also occured to me that it would be very
useful to have the XRDS-related bits of the XRI resolution spec in a
separate document that we could reference, since our new
protocol-agnostic core Auth 2.0 spec has no need for the rest of XRI
resolution. I wonder if the XRI guys would consider making Chapter 3 of
the XRI Resolution 2.0 spec into a separate document that OpenID Auth
could reference directly?

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


RE: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
Works for me, one thing though is the Yadis spec specifically highlights
the bits of the XRDS file which are relevant in this sort of use case.
If chapter 3 is separate then this would be a smaller concern for me,
but I think part of the *ugh* feeling people get is having to read about
the full XRDS schema.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 12:17 PM
Cc: specs@openid.net
Subject: Re: Modularizing Auth 2.0 Discovery

Recordon, David wrote:
 Well there already is the Yadis spec.  Maybe the Yadis spec remains 
 separate versus becoming part of the OASIS XRI Resolution document?
 

The XRDS-related parts of the Yadis specification seem to duplicate
requirements from XRI Resolution chapter 3.

In the interests of avoiding redundancy, I'd suggest the following
distinction:
  1. XRI Resolution chapter 3 (or a separate spin-off spec) describes
the syntax of an XRDS document.
  2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS
URL.
  3. OpenID Authentication describes how to determine the endpoint URI
and other information from an XRDS document, referencing [1].
  4. The new HTTP discovery specification would reference [2] and [3] to
describe the XRDS-based HTTP discovery mode, and then go on to describe
the HTML-based discovery fallback.

Alternatively, [3] above could be served by a separate spec OpenID
discovery using XRDS, though I think that may be overkill for something
so straightforward.

___
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: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
I'd be happy with either approach. One spec with a section on each type
or separate specs for each.  I think small separate specs are slightly
harder to comprehend, though make it easer for things like the SMTP
extension to develop.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 12:24 PM
Cc: specs@openid.net
Subject: Re: Modularizing Auth 2.0 Discovery

Drummond Reed wrote:
 
 Under this approach, discovery all identifiers (URLs, XRI 
 i-names/i-numbers, email addresses, phone numbers, etc.) would be
handled by OpenID Discovery.
 

I disagree that a single spec can contain discovery rules for all
conceivable discovery types without becoming ridiculously big. The
discovery rules in the current spec for just handling HTTP/HTTPS and XRI
discovery are already big enough.

However, I clearly have a bias for lots of small specs over one large
spec, and clearly your bias is the opposite. :)

___
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: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
Yeah, I'd see this either as a Yadis 1.1 (using things like LocalID
versus OpenID:Delegate) or have the OpenID URL Discovery spec replace
Yadis, referencing chapter 3 as needed.

I think I'd lean toward swallowing Yadis in as a part of this spec so it
is one fewer documents people need to read in total.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 12:27 PM
To: specs@openid.net
Subject: Re: Modularizing Auth 2.0 Discovery

Recordon, David wrote:
 Works for me, one thing though is the Yadis spec specifically 
 highlights the bits of the XRDS file which are relevant in this sort
of use case.
 If chapter 3 is separate then this would be a smaller concern for me, 
 but I think part of the *ugh* feeling people get is having to read 
 about the full XRDS schema.
 

Perhaps then Yadis (or something else) can describe the subset of the
XRDS schema used for service discovery, referencing the full XRDS
specification only as a formality?

I agree that XRI Resolution chapter 3 is a bit big for our purposes.


___
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: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Recordon, David
I'd like to stay away from changing it much, but I do agree there are
some warts which have been found.  Also by taking advantage of things in
the XRDS schema which exist now such as the LocalID element we'd be able
to remove the OpenID XMLNS for example.

--David 

-Original Message-
From: rob [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 28, 2007 1:03 PM
To: Recordon, David
Cc: Martin Atkins; specs@openid.net
Subject: Re: Modularizing Auth 2.0 Discovery

Recordon, David wrote:
 I think I'd lean toward swallowing Yadis in as a part of this spec so 
 it is one fewer documents people need to read in total.
+1

does this open up the potential to change Yadis?  I certainly found the
spec confusing on a few points when I first read it i.e.

1) Two xml namespaces, why?
2) Confusing namespace names, xri://$xrd*($v*2.0) this is just plain
confusing for someone not familiar with i-names.
3) Then finally this text If a Yadis XRDS includes more than one XRD
element, the Yadis Resource Descriptor is the last XRD element. A
Relying Party Agent MAY ignore other XRD elements. Again, just confused
me, couldn't see the point of the seemingly redundant xrd element or
understand when there would be more than one.
/
/Rob



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


RE: Proposal: An anti-phishing compromise

2007-02-08 Thread Recordon, David
Maybe laws are meant to be broken.  I don't see why a RP knowing that I
used a token as a second factor is a bad thing.  If nothing else, the
technology should support the OP providing that information and the OP's
implementation can let me as the user decide if I want to.  Just like
the trust request, it isn't mandated by the spec but every worthwhile OP
does it.

My $0.02.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Sunday, February 04, 2007 11:42 PM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise


On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote:
 Add a single, required, boolean field to the authentication response 
 that specifies whether or not the method the OP used to authenticate 
 the user is phishable. The specification will have to provide 
 guidelines on what properties an authentication mechanism needs to 
 have in order to be non-phishable. The field is just meant to 
 indicate that the authentication mechanism that was used is not a 
 standard secret entered into a Web form.

 The receiver should decide what is 'non-phishable', not the sender, so

 it would be better if the OP just states what mechanism was used, 
 perhaps.

Per Kim's laws, how I authenticate to my OP is none of the RP's
business.
That I authenticated in a phishing resistant manner is.

ie. we want the OP to make the statement that it followed certain
anti-phishing guidelines.

There is no certainty that the OP followed them, but the RP and user
have recourse against an OP if the OP stated that it did follow the
anti-phishing guidelines.

-- 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: Proposal: An anti-phishing compromise

2007-02-08 Thread Recordon, David
I agree that things like age should be in an extension, though I think
this single piece of data is useful in the core protocol.  I'm sure the
exact definition of phishing resistant will come back to bite us in
sometime in the future, but lets deal with it then instead of not adding
anything now.  I really like the idea that there be one thing in the
core spec which reaches out to each extension.

 - openid.identity - simple reg or profile exchange (on the basis that
the URL is an attribute)
 - openid.phishing_resistant - AQE

I think this is a good model to follow.

From the AQE perspective, I agree with you that using URLs for
authentication types makes sense, though profiling the entire document
beyond that I think is overkill.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Monday, February 05, 2007 12:01 AM
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise

Hi Josh

A few comments:

1) I think this should be an extension following previous arguments that
AuthN Age should be an extension. (AuthN Age would be another good item
in this extension) This allows an OP to advertise if it supports a
specific security profile.

2) It would be future proofing to view a phishing resistance as one of
many security profiles. Strong Authentication could be another one.

3) The RP should be able to request that one of more security profiles
are used. Not all RPs will require a particular profile, so provides a
nice security gradient.

4) The phishing resistant profile should be a URI, so that new ones can
be created in the future. The profile would not state specifically how
authentication was done, but would set a bar on what needed to be done
to provide a level of assurance that the user had not been phished. As
technology advances, new security profiles will likely be developed,
which could then be deployed, advertised by the OP, and requested by RPs


Summary of process:

RP does discovery on OP to see if it supports the desired security
profile. If the profile is not supported by the OP, then the RP may
abort the transaction and provide the user with

The RP expresses the desired security profile in the request. eg.:


openid.sp.request=http://specs.openid.net/sp/phishing-resistant-A

The OP executes on the desired security profile and states it has in the
response. eg.:


openid.sp.response=http://specs.openid.net/sp/phishing-resistant-A

The RP checks the security profile in the response and proceeds
accordingly.


On 1-Feb-07, at 1:41 PM, Josh Hoyt wrote:

 Hello,

 I've written up a proposal for an addition to the OpenID 
 Authentication 2.0 specification that addresses the phishing problem.
 I've had some off-list discussion of it, and I think it may strike the

 right balance. Please provide feedback.

 Josh

 Background
 ==

 We have had a lot of good discussion about how phishing relates to 
 OpenID. There seems to be consensus that the OpenID Authentication 
 spec should address these issues, but not consensus on how that should

 happen.

 The ways that OpenID can potentially make phishing worse:

  * Redirects to your provider are a fundamental part of the flow of 
 OpenID, so being redirected to a phishing site is easy to miss

  * Every relying party (necessarily) needs to know who the provider is

 in order to verify the authentication response. This means that the 
 site knows what UI it needs to use to phish (and even worse, it can 
 just proxy the user to the provider)

 I think these two issues cover what makes phishing potentially a 
 greater threat when using OpenID.

 Although these problems are significant, if a user can authenticate to

 their OpenID provider through an non-phishable mechanism, OpenID can

 make the phishing problem *less* of a threat, because there are fewer 
 places that will need to ask for credentials.

 Other relevant issues:

   * There is no universally deployed solution to the phishing problem

   * There is not even a universally *accepted* solution to the 
 phishing problem

   * Any technology that prevents phishing will require user-agent 
 support or else will fundamentally change the flow of OpenID (prevent 
 relying-party-initiated sign-in)

   * OpenID is intended to be deployed without requiring specific 
 technologies to be present in the user-agent

   * Any general anti-phishing technology can be applied to OpenID

 Proposed Change
 ===

 Add a single, required, boolean field to the authentication response 
 that specifies whether or not the method the OP used to authenticate 
 the user is phishable. The specification will have to provide 
 guidelines on what properties an authentication mechanism needs to 
 have in order to be non-phishable. The field is just meant to 
 indicate that the authentication mechanism that was used is not a 
 standard secret entered into a Web form.

 Analysis
 

 This 

RE: Proposal: An anti-phishing compromise

2007-02-08 Thread Recordon, David
Rogue RPs can already go and find RPs out there and manually look to see which 
just use usernames and passwords.  I don't see how providing this information 
actually makes the issue worse.  I agree that it makes it more apparent, but 
I'd hope that it would scare users and get them to go use a better OP.  An OP 
lying only hurts its users.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Friday, February 02, 2007 5:01 AM
To: specs@openid.net
Subject: Re: Proposal: An anti-phishing compromise

Recordon, David [EMAIL PROTECTED] schrieb/wrote:
 Add a single, required, boolean field to the authentication response 
 that specifies whether or not the method the OP used to authenticate 
 the user is phishable. The specification will have to provide 
 guidelines on what properties an authentication mechanism needs to 
 have in order to be non-phishable. The field is just meant to 
 indicate that the authentication mechanism that was used is not a 
 standard secret entered into a Web form.

What should the RP do with that flag? If they lock out users who are 
phishable, OP will simply start to lie about their non-fishability.

The main problem, however, is that it actually adds to the phishing problem by 
providing rouge RPs valueable information about security risks.

Claus


___
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: An anti-phishing compromise

2007-02-01 Thread Recordon, David
I'm in support of this idea.  I think a single parameter in the OP's
response will pave the path to integrate solutions to the phishing
problem and scales up to the AQE extension as it is re-worked.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, February 01, 2007 1:42 PM
To: OpenID specs list
Subject: Proposal: An anti-phishing compromise

Hello,

I've written up a proposal for an addition to the OpenID Authentication
2.0 specification that addresses the phishing problem.
I've had some off-list discussion of it, and I think it may strike the
right balance. Please provide feedback.

Josh

Background
==

We have had a lot of good discussion about how phishing relates to
OpenID. There seems to be consensus that the OpenID Authentication spec
should address these issues, but not consensus on how that should
happen.

The ways that OpenID can potentially make phishing worse:

 * Redirects to your provider are a fundamental part of the flow of
OpenID, so being redirected to a phishing site is easy to miss

 * Every relying party (necessarily) needs to know who the provider is
in order to verify the authentication response. This means that the site
knows what UI it needs to use to phish (and even worse, it can just
proxy the user to the provider)

I think these two issues cover what makes phishing potentially a greater
threat when using OpenID.

Although these problems are significant, if a user can authenticate to
their OpenID provider through an non-phishable mechanism, OpenID can
make the phishing problem *less* of a threat, because there are fewer
places that will need to ask for credentials.

Other relevant issues:

  * There is no universally deployed solution to the phishing problem

  * There is not even a universally *accepted* solution to the phishing
problem

  * Any technology that prevents phishing will require user-agent
support or else will fundamentally change the flow of OpenID (prevent
relying-party-initiated sign-in)

  * OpenID is intended to be deployed without requiring specific
technologies to be present in the user-agent

  * Any general anti-phishing technology can be applied to OpenID

Proposed Change
===

Add a single, required, boolean field to the authentication response
that specifies whether or not the method the OP used to authenticate the
user is phishable. The specification will have to provide guidelines on
what properties an authentication mechanism needs to have in order to be
non-phishable. The field is just meant to indicate that the
authentication mechanism that was used is not a standard secret entered
into a Web form.

Analysis


This proposal is a simplification of the Assertion Quality Extension [1]
(AQE), and is essentially the same as what Ben Laurie proposed earlier
[2]. It does not attempt to replace the AQE or require it for
authentication in general.

Benefits


The proposal is trivial implement, it acknowledges that phishing is a
problem, and forces implementers think about it. If more assurances are
required, then the AQE, whitelists, and other mechanisms still need to
be employed. This field just sets a minimum bar.

I think that this is the right information to require, because it
addresses this one thing that makes OpenID potentially worse for
security, but it does not mandate specific technologies.

It pushes the liability for phishing relying parties to OpenID
providers, who are the ones who should be responsible for taking
measures to prevent phishing. IANAL, so I don't know if this has any
real teeth, but it does make it clear to people who are implementing
OpenID providers that it is intended to be their responsibility to deal
with the phishing issues.

Drawbacks
-

It may be tricky to define what is meant by non-phishable.

There is no way for a Relying Party to *ensure* that the OpenID provider
indeed uses non-phishable authentication.

If libraries are used, the library user may not read the relevant parts
of the specification about phishing, and so may remain ignorant of the
phishing issues.

Why this should be in the core spec
---

I believe that this one piece of information would be required more
often than not, given the phishing implications. The prominence of being
in the core specification makes it harder to ignore the phishing
problem.

References
==

1.
http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
2. http://openid.net/pipermail/general/2007-January/001340.html
___
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: An anti-phishing compromise

2007-02-01 Thread Recordon, David
I think we all agree that talking about the method used is far more
useful, though with this proposal we're really trying to balance it with
simplicity in the authentication protocol itself.  Maybe it is better to
phrase the discussion around if the user provided a secret (password) to
the OP or not to authenticate versus talking about phishing directly.?.

I'd hope that this parameter in the auth spec really helps bring the
discussion around to the Assertion Quality Extension and that it be
implemented to provide the more robust metadata such as what type of
authentication was actually preformed.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of john kemp
Sent: Thursday, February 01, 2007 7:13 PM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise

Granqvist, Hans wrote:

 Proposed Change
 ===

 Add a single, required, boolean field to the authentication response 
 that specifies whether or not the method the OP used to authenticate 
 the user is phishable. The specification will have to provide 
 guidelines on what properties an authentication mechanism needs to 
 have in order to be non-phishable. The field is just meant to 
 indicate that the authentication mechanism that was used is not a 
 standard secret entered into a Web form.
 
 The receiver should decide what is 'non-phishable', not the sender, so

 it would be better if the OP just states what mechanism was used, 
 perhaps.

Agreed. A statement as to the phishability or not seems to be too
vague to be useful. A simple statement of the authentication method used
would seem to give the same effect, while providing potentially useful
information (assuming the RP trusts statements from the OP at all.)

 
 
 Benefits
 

...

 Here's what I think:
 
 Since the association step is hardly ever used, it can much more 
 easily be overloaded with extra information without breaking any 
 implementation.
 
 If the OP would *require* an OpenID association step from the RP, then

 this step can include an exchange of meta-information between OP and 
 RP.

How does the association step between OP and RP change the relationship
between the OP and the user (agent)?

I thought the attack we were considering is when a rogue RP directs the
user agent to a rogue OP, who then steals the user's credentials? How is
that affected by the rogue RP and rogue OP associating?

- John
___
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: DRAFT 11 - FINAL?

2007-01-31 Thread Recordon, David
I'm happy changing it from AJAX.  I think it was originally used since
AJAX is a bit overloaded already and people normally understand the
flashy non-reloading sort of thing when saying it.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Wednesday, January 31, 2007 12:50 PM
To: specs@openid.net
Subject: Re: DRAFT 11 - FINAL?

On 1/31/07, Martin Atkins [EMAIL PROTECTED] wrote:
 I think the spec is misusing the AJAX abbreviation a bit here, since 
 the usual approach to doing this doesn't involve XMLHttpRequest at 
 all, but instead works something like this:

*snip*

Yeah I've implemented a pure javascript demo this way (which works if
the OP does a http redirect back to the RP instead of submitting a
form).


 So no, this isn't really AJAX in the usual sense. As you noted, you 
 can't do OpenID Auth client-side with XMLHttpRequest because of the 
 same-origin restriction. You also can't do OpenID on the server 
 because then the user's session cookie won't end up at the OP during 
 the request. It still achieves the desired effect of doing an OpenID 
 auth request without disturbing the current page, though.

So should wording other than AJAX be used in the spec?
Or do we just point to an explanation on the wiki.

-Rowan
___
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: Tiny RDF Schema at openid.net?

2007-01-30 Thread Recordon, David
I'm not an RDF/OWL expert, though that looks reasonable to me.  How do
we deal with Auth 1.x which uses openid.server and openid.delegate
versus Auth 2.0 which uses openid2.provider and openid2.local_id?

--David

-Original Message-
From: Benjamin Nowack [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 29, 2007 10:13 AM
To: Recordon, David; Scott Kveton; specs@openid.net
Cc: [EMAIL PROTECTED]
Subject: RE: Tiny RDF Schema at openid.net?

On 29.01.2007 07:53:15, Recordon, David wrote:
I'd be happy to do it; I think we were talking about using 
xmlns.openid.net/foo as a format.
Awesome :)

I think the next step would be sending a copy of the RDF file for 
people here to look over. :)

I've attached a draft which contains already some nice2haves (e.g.
the OWL and isDefinedBy bits which may be helpful but are not strictly
necessary), I'm not 100% sure about the prose, and I guess DanC will
have a comment or two as well.

(The resource/about/ID attributes work similar to HTML's href/id, they
use the doc's URL as base, i.e. if the file was published at
http://xmlns.openid.net/auth, the full term URIs would be
http://xmlns.openid.net/auth#server etc.)

[[[
?xml version=1.0?
rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
  xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#;
  xmlns:owl=http://www.w3.org/2002/07/owl#;

  owl:Ontology rdf:about=
rdfs:labelOpenID Authentication Schema/rdfs:label
owl:versionInfo2007-01-29/owl:versionInfo
rdfs:comment
  A basic schema for core OpenID authentication terms.
/rdfs:comment
  /owl:Ontology
  
  rdf:Property rdf:ID=server
rdf:type
rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty/
rdfs:labelserver/rdfs:label
rdfs:comment
  The OpenID Identity Provider to be used for authentication.
/rdfs:comment
rdfs:isDefinedBy
rdf:resource=http://openid.net/specs/openid-authentication-1_1.html; /
  /rdf:Property
  
  rdf:Property rdf:ID=delegate
rdf:type
rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty/
rdfs:labeldelegate/rdfs:label
rdfs:comment
  The delegated OpenID Identifier to be used for authentication.
/rdfs:comment
rdfs:isDefinedBy
rdf:resource=http://openid.net/specs/openid-authentication-1_1.html; /
  /rdf:Property

/rdf:RDF
]]]

Best,
Ben



Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of Scott Kveton
Sent: Monday, January 29, 2007 7:42 AM
To: Benjamin Nowack; specs@openid.net
Cc: [EMAIL PROTECTED]
Subject: Re: Tiny RDF Schema at openid.net?

With just a quick look at this, it seems like a good idea.  I'd like to

see it happen somehow.

Anybody see any problems with doing this?

- Scott





On 1/29/07 2:13 AM, Benjamin Nowack [EMAIL PROTECTED] wrote:

 
 
 Hi,
 
 I was wondering if you guys could be persuaded to host a little RDF 
 Schema file on the openid.net site. As far as I can tell, there is 
 great support for OpenID among SemWeb folks as it can be combined 
 with

 things like FOAF for all sorts of cool applications.
 
 People recently started to write RDF extractors for the OpenID hooks 
 embedded in HTML (openid.server/delegate). As these hooks are in line

 with the Dublin Core guidelines [1], there are even multiple ways to 
 do this. The only thing we're missing for more widespread use is an 
 agreed-on namespace URI for the core openID terms (server and 
 delegate). And ideally this would be an openid.net one. So here is 
 my request: any chance we could put a little RDF Schema file on the 
 openid server? We would of course provide the file (it'd be just 5-10

 lines of XML), and the actual URL/path doesn't really matter. An 
 alternative could be to host it in some other stable URI space, Dan 
 Connolly (CC'd) might be able to provide one at w3.org, not sure. It 
 would be cool to get your blessing either way, though.
 
 
 Cheers in advance for perhaps considering it, Ben
 
 --
 Benjamin Nowack
 
 Kruppstr. 100
 45145 Essen, Germany
 http://www.bnode.org/
 
 
 [1] http://www.dublincore.org/documents/dcq-html/
 
 ___
 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: OpenID Auth 2.0 security considerations

2007-01-30 Thread Recordon, David
Is there a wiki page that exists to point to? Josh and Johnny, see any
issues with this?

Also any wording to propose Johannes?

Thanks,
--David

-Original Message-
From: Johannes Ernst [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 23, 2007 12:57 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Auth 2.0 security considerations

Given where we are in time, I would suggest to make the smallest amount
of changes possible to the document, i.e. leave everything as is, just
add this one link.


On Jan 23, 2007, at 11:59, Recordon, David wrote:

 I don't see a problem with that.

 Would you propose the majority of the security considerations section 
 in the current draft be moved to the wiki?  What would be the balance 
 between spec and wiki page?

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 Behalf Of Johannes Ernst
 Sent: Monday, January 22, 2007 12:15 PM
 To: specs@openid.net
 Subject: OpenID Auth 2.0 security considerations

 What about a non-normative link from the spec to a place on the wiki 
 where we can collect security considerations for it, and update those 
 in real-time as discussions such as the phishing one progress.



 ___
 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: DRAFT 11 - FINAL?

2007-01-30 Thread Recordon, David
Yeah, I'm not a big fan of openid2.* though it was the simplest method
of fixing up HTML discovery to work with multiple protocol versions.  I
know Josh thought about this more than I did though.

From what I've seen people do, it is AJAX between your server and
application, then OpenID's checkid_immediate between the server and OP,
with an AJAX response from your server to application.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Tuesday, January 30, 2007 2:02 PM
To: specs@openid.net
Subject: Re: DRAFT 11 - FINAL?

The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?

Also, the spec mentions AJAX interactions, but I don't see how you can
actually use AJAX with OpenID, since none of the responses are in XML
format .. it relies entirely on GET or POST redirection, not to mention
that you have to make cross-domain requests which XmlHttpRequest will
not do without extra security privileges.

(Or am I missing something?)

-Rowan
___
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: OpenID Auth 2.0 security considerations

2007-01-23 Thread Recordon, David
I don't see a problem with that.

Would you propose the majority of the security considerations section in
the current draft be moved to the wiki?  What would be the balance
between spec and wiki page?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Monday, January 22, 2007 12:15 PM
To: specs@openid.net
Subject: OpenID Auth 2.0 security considerations

What about a non-normative link from the spec to a place on the wiki
where we can collect security considerations for it, and update those in
real-time as discussions such as the phishing one progress.



___
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: 2.0 Spec Questions

2007-01-23 Thread Recordon, David
James, for 3 have you looked at
http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html?
I don't think it addresses the specific point you brought up, though may
be the right place to do it.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of James McGovern
Sent: Sunday, January 21, 2007 4:49 PM
To: specs@openid.net
Subject: 2.0 Spec Questions
Sensitivity: Confidential

Several questions after reading the 2.0 spec - draft 11.

1. The definition of realm if I am reading it correctly could be
problematic in large enterprises. For example, if one were using a web
access management product, they would have the ability to define a realm
in terms of a listing of discrete hosts that may or may not fit a URL
pattern matching approach.
For example, I could have a demographic called consumers who could
access hosts such as http://myconsumer.example.com ,
http://printstatements.example.com, http://paybills.example.com Likewise
another demographic called Business Partner may have a different set of
hosts they can interact with.

2. In terms of checking the nonce, can we recommend that a deployment
practice should be to use the NTP protocol and point to clocks of a
certain stratum? Likewise, would it be a good idea if an association
could indicate how much skew it would accept before rejecting?

3. In terms of an extension, should an OP be able to indicate when
reauth may be required so the user doesn't assume that if they
authenticate once they are always good?

4. Some portions of the spec are heavily coupled to PKI. How should
growing users of IBE think of this?


___
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: [OpenID] CROSS POSTING :-(

2007-01-22 Thread Recordon, David
I'd have to agree.  I realize I am guilty for the start of this thread 
announcing the new spec draft, though am hoping we can move this discussion to 
[EMAIL PROTECTED] if that works for people. 

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob
Sent: Monday, January 22, 2007 11:05 AM
To: heraldry-dev@incubator.apache.org; [EMAIL PROTECTED]; specs@openid.net; 
'openid-general'
Subject: [OpenID] CROSS POSTING :-(

This is getting a little insane - many of us are subscribed to the four lists 
that this thread has been posted to. 

One person has suggested that we actually consolidate the separate lists given 
the overlap in membership and topics (at least the openid lists). The other 
option is to be more disciplined about posting.

In any case, having most threads cross posted to 4 lists seems insane and 
unworkable to me.

What's the mood on consolidating the lists? I'd rather we just be careful about 
cross posting and keep the separate lists, but that may be too much to ask. 

-Gabe

P.S. Yes, I realize this is cross posted ;-)

 -Original Message-
 From: Marcin Jagodziński [mailto:[EMAIL PROTECTED]
 Sent: Monday, January 22, 2007 10:47 AM
 To: Ben Laurie
 Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general; 
 heraldry-dev@incubator.apache.org
 Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 
 - Implementor's Draft 11
 
 2007/1/22, Ben Laurie [EMAIL PROTECTED]:
  Actually, it appears to allow the RP to tell the OP what kind of 
  authentication was used, which is backwards.
 
  It also seems to be rather lacking in meat. Still, a step in the 
  right direction.
 
 
 I asked this question some time ago: is there any possibility for RP 
 to ask OP to use some authentication method? Or another scenario: how 
 can user select one of OP's for this particular authentication from 
 his Yadis file.
 
 regards,
 
 Marcin

___
general mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-19 Thread Recordon, David
I'm not sure what the right process is, though my hunch is that we'll
know the time is right once there are multiple working OpenID Auth 2.0
RPs and OPs on the web from different vendors that people are at least
testing with.  Until code that implements the spec exists in the wild, I
doubt we can really ultimately call it final.

That's just my take on it though...

--David 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 18, 2007 11:38 PM
To: heraldry-dev@incubator.apache.org
Cc: openid-general; specs@openid.net
Subject: Re: Announcing OpenID Authentication 2.0 - Implementor's Draft
11

David

A couple questions:

1) Would you like to set a deadline for final comments? Perhaps a week?

2) What is the approval process now? Is it still as posted at:

http://openid.net/specs.bml

Currently, the collective authors of OpenID Authentication (David
Recordon, Josh Hoyt, Dick Hardt, and Brad Fitzpatrick) oversee this
process and make the final determination of when a proposal has
matured.

-- Dick

On 18-Jan-07, at 7:35 PM, Recordon, David wrote:

 So with great pleasure I get to announce the culmination of about nine

 months of work between the OpenID, XRI, Sxip, and LID communities in 
 the drafting of OpenID Authentication 2.0.  This evening the editors 
 have published the final draft of the spec, which we now feel is in a 
 solid state for public implementations.

 There are already implementations in various languages 
 (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/,
 http://code.google.com/p/openid4java/,
 http://code.google.com/p/openid4perl/) supporting this spec and more 
 will emerge over the next few weeks.

 There will be another draft of the spec before it is considered final,

 though unless unforeseen implementation problems emerge these changes 
 will be further wordsmithing and cleanup.

 http://openid.net/specs/openid-authentication-2_0-11.html (dated
 today)

 Cool? Cool!

 --David



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


RE: DRAFT 11 - FINAL?

2007-01-18 Thread Recordon, David
Considering draft 11 hasn't been published yet, I don't see how we can
make it final at this point.  In addition, the file you link to is a few
patches old.  While I appreciate your enthusiasm, Josh, Johnny, and I do
have a process to this madness.

I know you know that we're really close, there is one remaining issue
Josh, Drummond, and I are tackling this afternoon, and then we'll
publish draft 11.

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Thursday, January 18, 2007 3:45 PM
To: specs@openid.net
Subject: DRAFT 11 - FINAL?

Hey List

To deal with the recent security concern postings about OpenID, language
was added to clarify a secure channel is needed between the OP and the
end-user's machine.

Are there any more issues with this specification:

http://openid.net/specs/openid-authentication-2_0-11.html

Can we make this final?

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


Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-18 Thread Recordon, David
So with great pleasure I get to announce the culmination of about nine
months of work between the OpenID, XRI, Sxip, and LID communities in the
drafting of OpenID Authentication 2.0.  This evening the editors have
published the final draft of the spec, which we now feel is in a solid
state for public implementations.

There are already implementations in various languages
(http://svn.apache.org/repos/asf/incubator/heraldry/libraries/,
http://code.google.com/p/openid4java/,
http://code.google.com/p/openid4perl/) supporting this spec and more
will emerge over the next few weeks.

There will be another draft of the spec before it is considered final,
though unless unforeseen implementation problems emerge these changes
will be further wordsmithing and cleanup.

http://openid.net/specs/openid-authentication-2_0-11.html (dated today)

Cool? Cool!

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


RE: Identity Based Encryption

2007-01-08 Thread Recordon, David
Hi James,
There has been some discussion, though normally around DTP
http://openid.net/specs/openid-service-key-discovery-1_0-01.html,
http://openid.net/specs/openid-dtp-messages-1_0-03.html,
http://openid.net/pipermail/specs/2007-January/001104.html.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of James McGovern
Sent: Saturday, January 06, 2007 3:43 AM
To: specs@openid.net
Subject: Identity Based Encryption
Sensitivity: Confidential

One of the things that is on my radar is the move towards identity-based
encryption (http://crypto.stanford.edu/ibe/). I am curious if anyone
hear has explored how it can work with OpenID? Hopefully we aren't
assuming PKI only? Has anyone invited the folks from Stanford and/or
Voltage to participate? If not, I will.


___
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: OpenID.net Service Type Namespaces

2007-01-05 Thread Recordon, David
Bringing this back up as now with more extensions I think we need at
least some sort of naming scheme.

I'd propose we use for roots:
http://specs.openid.net/authentication/VERSION...
http://specs.openid.net/extensions/ABBREV/VERSION...

Then corresponding:
http://xmlns.openid.net/extensions/ABBREV/VERSION/...

I'd lean against a date based naming scheme since it means that authors
always need to remember to update for each draft as well as library
developers writing code.

So for OpenID Authentication 2.0, I think this is basically the time to
change it or we leave it forever.  This means for the auth spec we would
have:
http://specs.openid.net/authentication/2.0/signon
http://specs.openid.net/authentication/2.0/server
http://specs.openid.net/authentication/2.0/identifier_select

So very verbose and organized.  There is no need for an xmlns for the
Auth 2.0 spec itself, since unlike the 1.1 spec which defined
OpenID:Delegate in Yadis, 2.0 takes advantage of the LocalID element
already defined in the XRD schema.

I'm obviously +1 for this naming scheme, want to get it right even
though we are beyond the eleventh hour.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 1:07 PM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: OpenID.net Service Type Namespaces

I get the hostname aspect for another namespace.

w3c[1] uses:

http://www.w3.org/ns/sss
http://www.w3.org//MM/

I have no strong opinion on it though

[1] http://www.w3.org/2005/07/13-nsuri

On 7-Nov-06, at 12:07 PM, Recordon, David wrote:

 Yeah, that is my concern.  Much easier to manage the namespace if this

 part is separate, then no matter what software is run for openid.net 
 anytime down the road we won't have issues.

 --David

 -Original Message-
 From: Drummond Reed [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 07, 2006 11:56 AM
 To: 'Dick Hardt'; Recordon, David
 Cc: specs@openid.net
 Subject: RE: OpenID.net Service Type Namespaces

 My understanding is that the concern is with potential conflicts in 
 the actual functioning of openid.net.

 Creating a clean DNS namespace for specs at specs.openid.net does seem

 like a good solution to me.

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 Behalf Of Dick Hardt
 Sent: Tuesday, November 07, 2006 8:09 AM
 To: Recordon, David
 Cc: specs@openid.net
 Subject: Re: OpenID.net Service Type Namespaces

 What is the concern? The argument for keeping it the current way is 
 for consistency. The URL resolution does not need to be trusted does 
 it?

 On 6-Nov-06, at 5:04 PM, Recordon, David wrote:

 I'm still concerned with using the openid.net/ namespace.
 Objections
 to using http://specs.openid.net/authentication/2.0/signon?  We don't

 need to change this in legacy stuff, just for 2.0 moving forward.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Saturday, October 21, 2006 7:34 PM
 To: Granqvist, Hans
 Cc: Recordon, David; specs@openid.net
 Subject: Re: OpenID.net Service Type Namespaces

 I am very supportive of an HTTP GET retrieving the specification.

 I think there are some issues with putting the date in the URL:

 1) the URL is unknown until the spec is completed. Any 
 implementations

 being done during the specification then have a moving target. The 
 URL

 is embedded in the Yadis document and I can see it causing some 
 headaches for people that it is not fixed until the end.

 2) the grouping is by time instead of by specification. If I want to 
 see all versions of a specification, it is not obvious

 Currently we have:
  http://openid.net/signon/1.0
  http://openid.net/signon/1.1
  http://openid.net/server/2.0
  http://openid.net/signon/2.0
  http://openid.net/identifier_select/2.0

 Given that the 1.x ones are already there, I would recommend we keep 
 using that scheme.

 -- Dick

 On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote:

 It has had some voices against it, but how about considering this 
 template (used in for example W3C xmldsig and
 xmlenc):

 http://openid.net/[year]/[month]/[project]#[type]

 Time-dependent (rather than version--dependent) namespaces can 
 evolve

 freely and will not be tied down to specific versioning numbers.

 Example:
 http://openid.net/2006/10/authentication
 http://openid.net/2006/10/authentication#signon


 It's cool if an HTTP GET on these links returns the specification.

 Once a spec is finalized, the then current year/month becomes that 
 spec's namespace. For example, xmlenc's namespace is 
 http://www.w3.org/2001/04/xmlenc

 Hans


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
 Sent: Friday, October 20, 2006 3:09 PM
 To: specs@openid.net
 Subject: OpenID.net Service Type Namespaces

 Right now we have things like http://openid.net

RE: Key Discovery In DTP Draft 3

2007-01-05 Thread Recordon, David
True, though why not still use this XML structure and the
RetrievalMethod element within the XRDS so that can then point to a
remote KeyInfo element in another XML document?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Grant Monroe
Sent: Friday, January 05, 2007 8:31 AM
To: Recordon, David
Cc: Carl Howells; specs@openid.net
Subject: Re: Key Discovery In DTP Draft 3

On 1/4/07, Recordon, David [EMAIL PROTECTED] wrote:
 Hey guys,
 Was looking at
 http://openid.net/specs/openid-service-key-discovery-1_0-01.html 
 tonight and curious why the decision was made to define the PublicKey

 / element which contains a link to the RSA key or X.509 certificate 
 versus embedding the key in the XRDS file?

I believe the rational was that KeyInfo objects can be quite large.
Especially if you have multiple services using them. We were concerned
about XRDSs getting really large. It doesn't make a whole lot of sense
to download a key for a service entry you aren't even interested in.

--
 Grant Monroe
 JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: [OpenID] Temporarily redirecting one's identity?

2007-01-04 Thread Recordon, David
I like this idea of using 307, though haven't thought through all the
repercussions of doing so.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Thursday, January 04, 2007 11:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [OpenID] Temporarily redirecting one's identity?

Sam Ruby wrote:
 Oh, dear.  I may have found an edge case.  And documented it in a 
 manner that others may follow.
 
 The documentation is here: 
 http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-SuperUsers
 
 The issue is that when somebody requests http://intertwingly.net/blog/

 and specifies an Accept: application/xrds+xml header on the request, I

 do a temporary 302 redirect to 
 http://intertwingly.net/public/yadis.xrdf
 
 The question is: when the identity validation is done, what should the

 RP view as my identity?  The original URI (.../blog/) or the
temporary
 one (.../yadis.xrdf)?
 
 LiveJournal (http://www.livejournal.com/openid/) choses the former. 
 JanRain (http://www.openidenabled.com/resources/openid-test/checkup)
 choses the latter.
 
 IMO, independent of whether or not I should be doing the redirect, the

 spec should be clear and one or both of these implementations should 
 be changed to conform.
 
 My two cents is that the answer should depend on whether it was a 
 permanent redirect (301) or a temporary redirect (302) which was
employed.
 
 However, if consensus forms on this mailing list, I'll update my 
 tutorial accordingly.
 

I believe that the spec doesn't make any distinction between permanent
and temporary redirects: any kind of redirect serves as a
canonicalization step (so, for example,
http://www.livejournal.com/users/frank/ becomes
http://frank.livejournal.com/) and so the ultimate destination URL is
used as the claimed identifier. (In other words, LiveJournal is
wrong.)

I admit that this is a bit irritating, but here's a workaround. Rather
than issuing a redirect, you can instead issue a response like this:

-
HTTP/1.1 200 OK
Content-type: text/html
X-XRDS-Location: http://intertwingly.net/public/yadis.xrdf
Vary: Content-type

pa href=http://intertwingly.net/public/yadis.xrdf;XRDS
Document/a/p
-

I will admit that this is ugly[1], but it should work with OpenID/Yadis
implementations in the wild today.

I don't remember the reason why a temporary redirect was made equivalent
to a permanent one, but this was discussed on a previous occasion. 
Perhaps someone can dig up the relevant thread in the archives.

At this point we probably can't make this change due to existing
implementations (though admittedly they do seem to be inconsistent right
now), so perhaps we could instead use a 307 Temporary Redirect[2]
response and retain the existing meaning of 301 and 302. I note that
Apache's Redirect directive *is* able to generate this response code. 
However, I fear that existing implementations might fail when faced with
this previously-undefined response code. Yadis is already finished, so
it might be too late to add this in now.


---

[1] Not least because the client said Accept: application/xrds+xml and
we returned a 200 OK (rather than a 406 Not Acceptable) but sent them a
text/html document!

[2] I'm not sure from the HTTP/1.1 spec whether I've got the semantics
of 307 correct, but it basically seems to be an alternative to 302 Found
which unambiguously says repeat that request at this new URL, rather
than 302 which in most browsers is implemented as Do a GET request on
this new URL instead of whatever you were doing before.

Legacy UAs don't understand the 307 code, but that's okay because only
Yadis clients are going to find this response useful anyway.

___
general mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Key Discovery In DTP Draft 3

2007-01-04 Thread Recordon, David
Hey guys,
Was looking at
http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight
and curious why the decision was made to define the PublicKey /
element which contains a link to the RSA key or X.509 certificate versus
embedding the key in the XRDS file?

From the research I've done tonight, it looks like the W3C in 2002
described how to do this as part of xmldsig.  Seems like we can just use
the KeyInfo element.
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo
They've also then recently put out a note describing the changes to that
document to match XML in 2006.
http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/

Is there something that I'm missing from the design standpoint as to why
this wasn't done?  If anything, it seems like it would reduce a fetch if
the key was in the XRDS file itself.

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


RE: Key Discovery In DTP Draft 3

2007-01-04 Thread Recordon, David
Oooh, interesting...

So looking at working draft 10
http://www.oasis-open.org/committees/download.php/17293 it seems that
3.2.5 is most relevant in that it describes
xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the
key would want to sit.  The only thing is that 3.2.5 is talking about
having the key present to verify a signature on the XRD file itself,
though in this case it may not actually be signed.

What I was toying with was something along the lines of:
Service
 
Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/
Type
  ds:KeyInfo
...
  /ds:KeyInfo
/Service

Thus it makes it easy for existing Yadis libraries to pick the key out
by the Type element.

--David

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 04, 2007 10:23 PM
To: Recordon, David; 'Carl Howells'; 'Grant Monroe'
Cc: specs@openid.net
Subject: RE: Key Discovery In DTP Draft 3

Just FYI, the xmldsig KeyInfo element is already part of the XRD schema
because the XRI Resolution spec uses it in the SAML form of trusted XRI
resolution. And either the SAML form or the HTTPS form of XRI trusted
res can give you the security characteristics in the Key Discovery spec.

That said, there can be advantages to managing the cert via an
independent service.

So I'm not coming down on either side (yet ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Thursday, January 04, 2007 10:07 PM
To: Carl Howells; Grant Monroe
Cc: specs@openid.net
Subject: Key Discovery In DTP Draft 3

Hey guys,
Was looking at
http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight
and curious why the decision was made to define the PublicKey /
element which contains a link to the RSA key or X.509 certificate versus
embedding the key in the XRDS file?

From the research I've done tonight, it looks like the W3C in 2002
described how to do this as part of xmldsig.  Seems like we can just use
the KeyInfo element.
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo
They've also then recently put out a note describing the changes to that
document to match XML in 2006.
http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/

Is there something that I'm missing from the design standpoint as to why
this wasn't done?  If anything, it seems like it would reduce a fetch if
the key was in the XRDS file itself.

--David
___
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 in Yadis

2007-01-04 Thread Recordon, David
So I'm trying to word this and it seems each extension mentions it
slightly differently.  Looking at the following, thoughts are
appreciated.

section title='Discovery'
  tIt is RECOMMENDED that OpenID Provider support of this
  extension be advertised within the XRDS document, described in
  xref target='OpenIDAuthentication2.0' /, when working with all
  versions of OpenID Authentication.  When doing so, the value of
the
  lt;xrd:Typegt; element MUST be
  http://openid.net/extensions/sreg/1.1;./t
/section

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Wednesday, January 03, 2007 9:45 PM
To: specs@openid.net
Subject: SREG in Yadis

Seems the 1.0 SREG spec doesn't mention advertising support in your
Yadis file.  With the 1.1 draft, seems like this should be mentioned.
Anyone against the Type being http://openid.net/extensions/sreg/1.1;
which is what the proposed openid.ns.sreg field value is?

http://openid.net/specs/openid-simple-registration-extension-1_1-01.html

--David
___
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: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID?

2007-01-03 Thread Recordon, David
My guess is that when a normal HTTP fetch is performed against
http://xri.net/=bobwyman, the proxy resolver expects you to be in a
browser and thus issues a 302 Redirect to your contact page.

One option is if the iBrokers (is it iBroker or i-broker?) included
Yadis on each contact page.  This would mean the OpenID Relying Party
would fetch http://xri.net/=bobwyman, be redirected to
http://2idi.com/contact/=bobwyman, and then have that URL to perform
discovery.  The problem this presents is that the Relying Party follows
redirects and canonicalizes the final URL as the Claimed Identifier.
This thus means you'd no longer be making a claim about
http://xri.net/=bobwyman, but rather that you own
http://2idi.com/contact/=bobwyman.  Thus if you change iBrokers, this
assertion would no longer remain valid.  It also removes the protection
the iNumber (and CanonicalID tag) adds to the XRI Resolution process
since i-names can be reassigned.

I'm unsure if there is some trickery that could be done in the Yadis
discovery document to resolve this, though really what I think would end
up is you would enter http://xri.net/=bobwyman to start the discovery
process, but then end up making an assertion about =bobwyman and not the
URL version of it.

Someone correct me here if my logic is wrong.

--David



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Wyman
Sent: Wednesday, January 03, 2007 8:44 PM
To: openid-general
Subject: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman
anOpenID?


My apologies if this is a really dumb question...
 
Why is it that I can do OpenID authentication with either of =bobwyman
or xri://=bobwyman but, according to the OpenIDEnabled checkup
http://www.openidenabled.com/resources/openid-test/checkup/start?openid
_url=http%253A%252F%252Fxri.net%252F%253Dbobwyman  page,
http://xri.net/=bobwyman is not a working OpenID?
 
bob wyman
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


SREG in Yadis

2007-01-03 Thread Recordon, David
Seems the 1.0 SREG spec doesn't mention advertising support in your
Yadis file.  With the 1.1 draft, seems like this should be mentioned.
Anyone against the Type being http://openid.net/extensions/sreg/1.1;
which is what the proposed openid.ns.sreg field value is?

http://openid.net/specs/openid-simple-registration-extension-1_1-01.html

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


RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?

2007-01-03 Thread Recordon, David
 Therefore it seems to me the best thing to do would be to have
 OpenID libraries recognize an HXRI (from the http://xri.* pattern)
 as a form of an XRI, drop the HXRI proxy resolver prefix, and
 proceed with it as an XRI so the user gets the i-name/i-number
 synonym benefits they expect.

I'd agree from a usability standpoint that would be the best
recommendation.  The only thing that would be a bit hard to explain is
that the library could still use http://xri.net as a proxy resolver.  So
the potentially confusing steps would be:
1) User enters http://xri.net/=bobwyman
2) RP sees prefix http://xri.net/=; and then extracts =bobwyman
3) RP constructs Yadis fetch on http://xri.net/=bobwyman for proxy
resolution of the i-name =bobwyman

--David

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 03, 2007 11:26 PM
To: Recordon, David; 'Bob Wyman'; 'openid-general'; specs@openid.net
Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman
an OpenID?

Bob, it's a great question, and David's correct as far as he goes, and
so is Johnny. However I suspect that the behaviour you're experiencing
is due to older OpenID libraries being used by the RP site at which
you're experiencing this behaviour.

Here's why: if you entered your i-name =bobwyman in URL format (we call
this an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is
correct that by both the 1.1 and (pending) 2.0 specs, this would be
considered a URL, and Yadis resolution should proceed on the URL.

However Yadis resolution means the RP library should first do an HTTP
GET on the URL with a content type of application/xrds+xml. Such a
request to an XRI proxy resolution server (which is what http://xri.net
is functioning as) should return you the XRDS document for the XRI
=bobwyman, exactly as Yadis would for any other URL that has its own
XRDS document.

In which case everything should work fine (except the issue of
http://xri.net/=bobwyman now being the Claimed Identifier, see below).
Because that's not happening, the RP library at the site you're testing
must not be doing Yadis resolution, or at least not requesting an XRDS
document type first. Instead it's just doing a plain http GET with no
content type, in which case the HXRI proxy resolver is returning a
redirect to the default service endpoint in the XRDS document per the
XRI Resolution spec.

Since for most i-names, the default service endpoint is the registrant's
contact page, at least one i-broker, 1id.com, has cleverly got around
this non-Yadis-compliant behaviour by adding the necessary OpenID link
elements to the HTML of the contact page. (Victor Grey at 2idi told me
today that he plans to implement the same workaround.)

While this is a smart workaround, it shouldn't be necessary if the
library just does Yadis resolution in the correct order on the HXRI.

However all of this still leaves the open issue that Johnny raised,
namely that the current draft OpenID Authentication 2.0 spec treats
=bobwyman and http://xri.net/=bobwyman as separate identifiers.
Ironically, in XRI Syntax
2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI
Resolution 2.0 Working Draft 10, but we need to make it a formal part of
XRI Syntax), and we are making it very explicit that from the standpoint
of equivalence, the proxy resolver prefix of any HXRI is NOT part of the
XRI.
In other words, the following two identifier...

http://xri.net/=bobwyman
=bobwyman

...are equivalent XRIs because the former is really just the HXRI proxy
resolver prefix http://xri.net; plus the absolute XRI =bobwyman.

Therefore it seems to me the best thing to do would be to have OpenID
libraries recognize an HXRI (from the http://xri.* pattern) as a form of
an XRI, drop the HXRI proxy resolver prefix, and proceed with it as an
XRI so the user gets the i-name/i-number synonym benefits they expect.

Johnny, David, Josh: do you agree?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Wednesday, January 03, 2007 8:55 PM
To: Bob Wyman; openid-general; specs@openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't
http://xri.net/=bobwymananOpenID?

My guess is that when a normal HTTP fetch is performed against
http://xri.net/=bobwyman, the proxy resolver expects you to be in a
browser and thus issues a 302 Redirect to your contact page.

One option is if the iBrokers (is it iBroker or i-broker?) included
Yadis on each contact page.  This would mean the OpenID Relying Party
would fetch http://xri.net/=bobwyman, be redirected to
http://2idi.com/contact/=bobwyman, and then have that URL to perform
discovery.  The problem this presents is that the Relying Party follows
redirects and canonicalizes the final URL as the Claimed Identifier.
This thus means you'd no longer be making a claim about
http://xri.net/=bobwyman, but rather that you own
http://2idi.com/contact

RE: Questions on Protocol

2007-01-02 Thread Recordon, David
That sounds great to me!  I like the model of starting here and growing
as needed. :)
 
--David



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Tuesday, January 02, 2007 10:12 AM
To: McGovern, James F ((HTSC, IT))
Cc: specs@openid.net
Subject: Re: Questions on Protocol


Welcome, James. For my part, I know for sure that authorization comes up
fairly regularly in the context of OpenID, so it's great you are
stepping up to help us all find some answers! 

I would suggest that we start this work here, and if there is too much
traffic, we move it off to a new list. 

On Jan 2, 2007, at 8:57, McGovern, James F ((HTSC, IT)) wrote:


Johannes invited me to lead the development of the specification
for including relationships and authorization as part of OpenID. I have
the following questions:

1. Would it be too distracting to have the conversation occur on
this listserv or should the admin establish another one?

2. I would also like to get a dialog going around how OpenID
would need to work in order to support notions such as Identity
propagation, integration into BPM and ECM platforms and support for
Identity Based Encryption





*
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: Consistency of negative responses to checkid_immediate requests

2006-12-27 Thread Recordon, David
I think using cancel would add consistency between the modes, any
reason I'm not seeing why it is a bad choice?

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Tuesday, December 26, 2006 4:17 PM
To: Johnny Bufu
Cc: Martin Atkins; specs@openid.net
Subject: Re: Consistency of negative responses to checkid_immediate
requests

Reviving an old thread...

On 12/14/06, Johnny Bufu [EMAIL PROTECTED] wrote:
 On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
  On 12/13/06, Martin Atkins [EMAIL PROTECTED] wrote:
  Josh Hoyt wrote:
  It's confusing to me make the failure response to an immediate 
  mode request be id_res, especially if that is not the failure 
  response for setup mode. I can't see a reason that they can't both

  use the cancel response to indicate that the OP or end user do 
  not wish to complete the transaction.
 
  This is a very minor change, but it will make the spec simpler.
 
  I think the RP will want to do something different in these two 
  cases.
 
  That's true, but the RP will probably need to handle the success 
  case differently for immediate mode anyway (e.g. it will have to do 
  AJAX to update the page) so I expect it to have a specific return_to

  URL for immediate requests. Since using a different return_to is 
  trivial, I prefer the consistency of negative responses.

 The current / v1 modes will need to be mentioned in the compatibility 
 section, and also implemented. Not sure if this simplification will 
 then still be worth.

Since the user_setup_url parameter is now gone, there is no way to
differentiate between a broken/truncated response and a cancel response
to an immediate mode request.

I think that there needs to be *some* positive way to identify
cancellation of immediate mode requests, rather than depending on lack
of other parameters. I'd be happy with any of these ways to positively
identify a cancel response to checkid_immediate:

 1. re-using cancel as I suggested above

 2. introducing a new mode (e.g. setup_needed )

  3. adding a parameter that the id_res response is an immediate
cancellation (e.g. openid.setup_needed=true)

I no longer buy the argument about having to support the OpenID 1
mechanism in the library, since cancellation of an immediate mode
response is already indicated differently between OpenID 1 and 2, so
it's really just a matter of what goes into the OpenID 2 code path
rather than whether the two code paths exist.

Pseudo-code for the current approach:

def isSetupNeeded():
  if this is OpenID 1:
return whether there is a user_setup_url parameter

  if this is OpenID 2:
# This is the branch that I want to change
return whether there are any other OpenID parameters passed at all

Thoughts?

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


RE: OpenID Exchange

2006-12-14 Thread Recordon, David
Awesome, glad to see this!  Would be great as Johannes said to see some
flow examples and how you'd see it integrate to do something like
exchange profile data or post a photo on your blog.  Would love to see
this formalized and happy to help however I can!

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Wednesday, December 13, 2006 4:44 AM
To: specs@openid.net
Subject: OpenID Exchange


I have made an early draft of a spec called OpenID Exchange on the wiki:
 http://openid.net/wiki/index.php/OpenID_Exchange_1.0

The goal of this protocol is to allow user-accompanied HTTP requests. 
user-accompanied means that a consumer makes a request to a service on
behalf of a user and the user reviews and approves the request.

Example applications of this include:
  * Zooomr posting photos into your blog with your one-time approval,
without disclosing your login credentials. [1]
  * Fetching of user profile information.
  * Social networking friendship handshakes. [2]

The protocol should, in theory, be able to act as a transport for any
HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET
requests. The protocol for post in my blog could, for example, just be
an AtomAPI POST request made over OpenID Exchange.

This is still work-in-progress. The spec needs lots of refinement and at
some point I'll have to make a demo or two.

[1] You can still see the results of the demo of my earlier version
of this on LiveJournal, albeit without the pictures:
 http://openrpcdemo.livejournal.com/

[2] Discussed further in my blog entry on social networking:
 http://www.apparently.me.uk/623.html


___
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: OpenID IPR Policy Draft

2006-12-07 Thread Recordon, David
Brett,
We certainly are going to be working with our counsel, though first wanted to 
make sure we captured the community's intent.

--David


 -Original Message-
From:   Brett McDowell [mailto:[EMAIL PROTECTED]
Sent:   Thursday, December 07, 2006 06:47 AM Pacific Standard Time
To: Recordon, David
Cc: [EMAIL PROTECTED]; specs@openid.net
Subject:Re: OpenID IPR Policy Draft

This is normally lawyer work.  I recommend the companies  individuals invested 
in OpenID immediately turn this exercise over to your legal counsel to ensure 
your interests--and the interests of the community--are protected 
appropriately. 

Does the new OpenID organization have legal counsel retained (I don't mean 
volunteers, but actually hired)?  If not, that would be my second 
recommendation.

--Brett


On 12/6/06, Recordon, David [EMAIL PROTECTED] wrote:

Hey guys,
Been working with Gabe, and others, on starting to draft an IPR Policy
for OpenID specifications.  We'd appreciate feedback in terms of if what
is written captures the correct intent of the community?  We realize the 
language isn't technically as tight as it needs to be, though first want
to make sure it is saying the right thing.  It is largely based on the
IPR Policy for Microformats.

 http://openid.net/wiki/index.php/IPR_Policy 
http://openid.net/wiki/index.php/IPR_Policy

Thanks,
--David
___
specs mailing list
specs@openid.net
 http://openid.net/mailman/listinfo/specs 
http://openid.net/mailman/listinfo/specs





-- 
Brett McDowell +1.413.662.2744 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


OpenID IPR Policy Draft

2006-12-06 Thread Recordon, David
Hey guys,
Been working with Gabe, and others, on starting to draft an IPR Policy
for OpenID specifications.  We'd appreciate feedback in terms of if what
is written captures the correct intent of the community?  We realize the
language isn't technically as tight as it needs to be, though first want
to make sure it is saying the right thing.  It is largely based on the
IPR Policy for Microformats.

http://openid.net/wiki/index.php/IPR_Policy

Thanks,
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: OpenID Simple Registration 1.1 - Draft 1

2006-12-06 Thread Recordon, David
Done, commit 172.

--David 

-Original Message-
From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 06, 2006 1:41 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Simple Registration 1.1 - Draft 1

# Please review and +1 or -1 for final draft.  Only change is adding #
namespace parameters to request and response to work as a 2.0 #
extension.  It also doesn't hurt to have these parameters in 1.1 #
messages.

+1, but please change my email address in the authors list to
[EMAIL PROTECTED]

Thanks,

--
  Jonathan Daugherty
  JanRain, Inc.

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


RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft

2006-12-03 Thread Recordon, David
Yeah, we looked at this a bit when drafting the extension originally.
There are just so many factors that go into password choice/enforcement
that describing them becomes quite difficult.  It also is possible to
describe features which actually are just red herrings.  I wish it was
simpler so something could be included. :-\

Also pulling general@ off this thread.

--David 

-Original Message-
From: Avery Glasser [mailto:[EMAIL PROTECTED] 
Sent: Saturday, December 02, 2006 8:35 PM
To: [EMAIL PROTECTED]
Cc: Recordon, David; specs@openid.net; [EMAIL PROTECTED]
Subject: RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft

Daniel,

It's not a bad idea, but it doesn't actually drive any more knowledge
about the security of the authentication. There are so many factors when
calculating the entropy and overall security of a password that I don't
think it should be included in the AQE.

Listing the password length, the criteria for the password, how long
since last password change and other factors should probably be either
part of the Attribute Exchange or the eventual convergence/alignment
with SAML AC.

- Avery


It might be useful to some RP's to know of any complexity schemes put 
on users' passwords.

How about:

password.min_length=8
password.max_length=16

the number of characters that the password is between.
password.max_length would probably be more useful as I don't see many 
RP's complaining if the OP allows for long passwords. I can see the RP 
wanting my password to be at least for characters though.

password.complexity=alphanumeric,mixed-case

a comma separated list of common restrictions to the password's format.

Some possible values: none, numeric, alpha, alphanumeric, 
lower-case, upper-case, mixed-case, non-dictionary, 
case-insensitive

none or omitting one of the facets would have the effect of allowing 
alphanumeric characters of any case + possible some special characters.

case sensitive.

What do you think?

Daniel E. Renfer
http://kronkltd.net/

On 12/1/06, Avery Glasser [EMAIL PROTECTED] wrote:
 All,

 Attached is the new XML for draft 2 of the AQE spec. It has been 
 checked into SVN as release 140.

 David, Can you convert it to HTML and repost it to the list?






 -- Avery

 ==
 Avery Glasser
 CTO
 VxV Solutions, Inc.

 + 1.415.992.7264 - office
 + 1.415.290.1400 - mobile
 + 1.415.651.9218 - fax

 329 Bryant Street, Suite 2D
 San Francisco, CA 94107

 email:  [EMAIL PROTECTED]
 i-name: =avery
 ==

 This e-mail (including any attachments), is confidential and intended

 only for the use of the addressee(s). It may contain information 
 covered by legal, professional or other privilege. If you are not an 
 addressee, please inform the sender immediately and destroy this 
 e-mail. Do not copy, forward, use or disclose this e-mail. Thank you.




--
==
Avery Glasser
VxV Solutions, Inc.

+ 1.415.992.7264 - office
+ 1.415.290.1400 - mobile
+ 1.415.651.9218 - fax

 
329 Bryant Street, Suite 2D
San Francisco, CA 94107
==

This e-mail (including any attachments), is confidential and intended
only for the use of the addressee(s). It may contain information covered
by legal, professional or other privilege. If you are not an addressee,
please inform the sender immediately and destroy this e-mail. Do not
copy, forward, use or disclose this e-mail. Thank you.

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


RE: OpenID Assertion Quality Extension - Draft

2006-11-29 Thread Recordon, David
Sorry for the spam, uploaded so now have perma-links and am calling it
Draft 1 since it is the first public draft:
http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html
http://openid.net/specs/openid-assertion-quality-extension-1_0-01.txt

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Wednesday, November 29, 2006 9:46 AM
To: specs@openid.net
Cc: [EMAIL PROTECTED]
Subject: OpenID Assertion Quality Extension - Draft

So this is the first public draft of the extension that Avery, Paul, and
I have been working on the past two weeks.  Definitely looking for
feedback about all aspects of it and it still has some gaps, though we
wanted to put it out there for comments.

Thanks,
--David

Abstract:
This extension to the OpenID Authentication protocol provides means for
a Relying Party to request additional information about the specifics by
which a user enrolled and/or authenticated to the OpenID Provider, as
well as for an OpenID Provider to add such information into assertions.
Such information may be necessary for use cases in which, for an RP to
make an assessment of the quality of an assertion from a OP, the OP's
identity is not on its alone sufficient (as might be the case were an OP
capable of authenticating a user through various authentication
mechanisms).

While there are other aspects of lifecycle management that may bear on
the resultant quality of an OpenID Authentication assertion - enrollment
and authentication are generally the two characteristics that are most
useful in distinguishing authentication quality. Consequently, we focus
on these aspects here. We expect that other aspects (e.g. security
characteristics, credential provisioning, etc) could be dealt with in
the future.

As an extension, it requires no changes to either the Yadis protocol or
the OpenID Authentication protocol and is viewed as an optional
extension though its use is certainly recommended.

We acknowledge that, while none of the information expressed via this
extension can be verified by the Relying Party in a technological
fashion, this need not be viewed as an issue. The lack of an inherent
trust model within OpenID allows for Relying Parties to decide which OPs
they trust using whatever criteria they choose - likewise RPs will
decide whether or not to trust claims as to authentication quality from
such OPs as well. 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


OP Identifier vs. OP-Specific Identifier

2006-11-19 Thread Recordon, David
So I'm working on cleaning up the terminology section with edits from
Drummond.  On first read I had no idea what the difference between OP
Identifier and OP-Specific Identifier were.  Now that my brain has
kicked in I do, but I have the feeling this is going to be really
confusing for others reading the specification.

I really think we need to get our terminology down, since right now it
is honestly quite confusing:
 - Identifier (umbrella definition)
 - Claimed Identifier (umbrella definition)
 - OP-Specific Identifier (needs context)
 - OP Identifier (needs context)
 - Public Identifier (tries to create context)
 - Private Identifier (tries to create context)
 - Privacy-protected login (have we even defined this)

How can we clean this up?  I think the problem is that we're trying to
describe features via the terminology section.

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


RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handlehttp://[EMAIL PROTECTED] Style Identifiers)

2006-11-13 Thread Recordon, David
I'm not sure if it would necessarily be thrown away, I guess it is
really up to the IdP.  With two identifiers, it is pretty easy to pass
to the IdP and let it decide what it wants to do.

1) I enter [EMAIL PROTECTED] as my identifier on the RP
2) RP does discovery on recordon.name and finds my IdP
3) RP constructs authentication request with openid.disco_id being
[EMAIL PROTECTED] and openid.identifier being
http://openid.net/identifier_select/2.0;

That was all I was looking for describing in my initial proposal.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Friday, November 10, 2006 11:23 AM
To: specs@openid.net
Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL]
Handlehttp://[EMAIL PROTECTED] Style Identifiers)

On 11/9/06, David Fuelling [EMAIL PROTECTED] wrote:
 So, '[EMAIL PROTECTED]' would be treated as if the User had entered 
 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form.

I don't like the idea of telling people to enter their username, and
then throwing it away. As mentioned below, [EMAIL PROTECTED] can map to a
valid http url. This really, I suppose, is a matter of choice on the
part of an IdP as to what sorts of instructions they give to their users
about identifying themselves to RPs.

Verisign's PIP does userx.pip.verisign.com Somone might do
example.com/user/x Someone else might do [EMAIL PROTECTED]

Discovery would be performed identically on all the above ... and we're
left with a problem of user education.

-Rowan
___
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: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

2006-11-13 Thread Recordon, David
Hey Adam,
Thanks for the insight!  I know, as Dick described, there was a design
decision made in terms of enabling payloads larger than 2Kb within
OpenID Authentication requests and responses.  With that said, there are
other approaches, such as using GET requests and including a token to
retrieve more data via OpenID DTP as a back-channel request.  So lots to
think about...

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adam Nelson
Sent: Sunday, November 12, 2006 5:25 PM
To: specs@openid.net
Subject: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with
REST/SOAP)

I've been tracking OpenID auth from 1.0 with great interest.  Last
summer Johannes Ernst explained to me how it was that one might use
openid to authenticate a non-interactive user agent such as a REST API
consumer by intercepting the RP's redirect and providing the info from
the IdP itself.  Given OpenID's design goals (decentralized,
lightweight, flexible identity management), and its seemingly inevitable
adoption into the mashup-minded web 2.0 ecosystem (God help me I'm
buzzwording!), it seems to me that OpenID's value is significantly
enhanced if the identities it enables can be used to authenticate to
SOAP and REST APIs as well as interactive web sites.

Having said that, I was surprised to note in draft 10 of OpenID Auth 2.0
that the HTTP redirect method of communication between the RP and the
IdP is deprecated in favor of an HTML forms-based approach.  This
suggests to me that OpenID Auth 2.0 is not compatible with REST or SOAP
or any other binding that doesn't involve the exchange, parsing, and
submission of HTML forms.

I'm curious why this decision was made, and if its implications have
been fully considered.  Has there been any thought given to an
alternative means of authentication, perhaps via custom HTTP headers or
some other non-HTML means?  If not, does this mean OpenID is not
intended to support authentication to programmatic APIs?

Thanks,
Adam
___
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: Went Through it With Brad

2006-11-13 Thread Recordon, David
Solution 1 seems like the most simple.  openid2 is a bit ugly, but
does resolve the problem.  Otherwise we'd have to do something like
Yadis discovery against the server endpoint which would make things more
complicated and meta.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
Hoyt
Sent: Monday, November 13, 2006 4:15 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Went Through it With Brad

On 11/8/06, Recordon, David [EMAIL PROTECTED] wrote:
 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is 
 a way to know that the IdP is using Auth 1.1.  While I know we believe

 Yadis will be used in most applications, I hypothesize that the 
 simplicity of HTML-based discovery will have it continue to prevail.  
 I thus would propose we remove the sentence saying that this is a way 
 to know that an IdP is running version 1.1.

Yeah, it does. The justification for this is that there is no way to
specify a version for the server, so we have to assume something, and
since HTML discovery already used in 1.1, that's the only reasonable
assumption to make. I see two ways out of this:

1. Add another rel value to the HTML discovery for OpenID 2:
  link rel=openid.server openid2.server href=...

2. Add some way of doing discovery on the endpoint URL for determining
the version, so it doesn't have to be part of the user's XRDS or HTML
document

Either one of these would let us keep the nice, simple HTML discovery
mechanism for 2.0.

Thoughts or ideas?

Josh

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


RE: OpenID.net Service Type Namespaces

2006-11-07 Thread Recordon, David
Yeah, that is my concern.  Much easier to manage the namespace if this
part is separate, then no matter what software is run for openid.net
anytime down the road we won't have issues.

--David 

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 11:56 AM
To: 'Dick Hardt'; Recordon, David
Cc: specs@openid.net
Subject: RE: OpenID.net Service Type Namespaces

My understanding is that the concern is with potential conflicts in the
actual functioning of openid.net.

Creating a clean DNS namespace for specs at specs.openid.net does seem
like a good solution to me.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Tuesday, November 07, 2006 8:09 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID.net Service Type Namespaces

What is the concern? The argument for keeping it the current way is for
consistency. The URL resolution does not need to be trusted does it?

On 6-Nov-06, at 5:04 PM, Recordon, David wrote:

 I'm still concerned with using the openid.net/ namespace.   
 Objections
 to using http://specs.openid.net/authentication/2.0/signon?  We don't 
 need to change this in legacy stuff, just for 2.0 moving forward.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Saturday, October 21, 2006 7:34 PM
 To: Granqvist, Hans
 Cc: Recordon, David; specs@openid.net
 Subject: Re: OpenID.net Service Type Namespaces

 I am very supportive of an HTTP GET retrieving the specification.

 I think there are some issues with putting the date in the URL:

 1) the URL is unknown until the spec is completed. Any implementations

 being done during the specification then have a moving target. The URL

 is embedded in the Yadis document and I can see it causing some 
 headaches for people that it is not fixed until the end.

 2) the grouping is by time instead of by specification. If I want to 
 see all versions of a specification, it is not obvious

 Currently we have:
   http://openid.net/signon/1.0
   http://openid.net/signon/1.1
   http://openid.net/server/2.0
   http://openid.net/signon/2.0
   http://openid.net/identifier_select/2.0

 Given that the 1.x ones are already there, I would recommend we keep 
 using that scheme.

 -- Dick

 On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote:

 It has had some voices against it, but how about considering this 
 template (used in for example W3C xmldsig and
 xmlenc):

 http://openid.net/[year]/[month]/[project]#[type]

 Time-dependent (rather than version--dependent) namespaces can evolve

 freely and will not be tied down to specific versioning numbers.

 Example:
 http://openid.net/2006/10/authentication
 http://openid.net/2006/10/authentication#signon


 It's cool if an HTTP GET on these links returns the specification.

 Once a spec is finalized, the then current year/month becomes that 
 spec's namespace. For example, xmlenc's namespace is 
 http://www.w3.org/2001/04/xmlenc

 Hans


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
 Sent: Friday, October 20, 2006 3:09 PM
 To: specs@openid.net
 Subject: OpenID.net Service Type Namespaces

 Right now we have things like http://openid.net/signon/1.1, 
 http://openid.net/sreg/1.0, etc.  This doesn't really seem to scale,

 populating the main http://openid.net namespace.

 Could we do something like
 http://specs.openid.net/authentication/2.0/signon or 
 http://specs.openid.net/authentication/2.0/identifier_select
 as well as then http://specs.openid.net/sreg/1.0?

 This would give all the specs their own namespaces, as well as make 
 it so we can do smart redirection from each of these type urls to 
 the correct anchor in the individual spec.

 --David
 ___
 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


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


RE: IdP's Advertising Both http and https

2006-11-07 Thread Recordon, David
Moving this to the list, I really should have started it there in the
first place.

--David

-Original Message-
From: Recordon, David 
Sent: Monday, November 06, 2006 2:06 PM
To: 'Dick Hardt'; Josh Hoyt
Subject: RE: IdP's Advertising Both http and https

Hey Dick,
But the security warnings will still exist:
 - RP redirects me to http on IdP
 - IdP redirects me to https on IdP for login page (warning)
 - I interact with IdP for trust request via https
 - I submit HTTPS form
 - IdP redirects me back to RP via http (warning) 

Am I missing something here?

The only way to remove all of the warnings is adding additional
redirects to itself in these steps to remove the warnings.

I guess I'm not sure what I think we should do, though don't think this
is a simple problem.

--David

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 04, 2006 6:49 PM
To: Recordon, David
Cc: Josh Hoyt
Subject: Re: IdP's Advertising Both http and https

Hi David

If the RP is only using HTTP, then then the request and response are in
the clear between the RP and user-agent, and using SSL between the
user-agent and OP has nominal benefit. In case it was not clear, the OP
SHOULD switch to HTTPS for all other transactions between the user-
agent and the OP, so user authentication is secure and any other
personal data transported while the user is deciding what to do is
secure.

I think many RPs will only be using HTTP, so this will be a usability
issue if they are seeing the browser warning.

... but perhaps I am not clear on what you were thinking you wanted to
do?

-- Dick

On 30-Oct-06, at 4:55 PM, Recordon, David wrote:

 So I was writing this one up for the notes and it just doesn't seem to

 be sitting well with me as I think about it more:

  - An IdP can already advertise both http and https endpoints in their

 Yadis files.  A RP should use the same schema when redirecting the 
 user to the IdP as it uses for its endpoints, though if this is not 
 possible can decide to not continue the transaction.  This is desired 
 due to browsers showing a security warning when redirecting from https

 to http and vice-versa.

 So if the RP is HTTP, I think the security benefits of using SSL for 
 the request (if the IdP offers a https endpoint) outweigh the fact 
 that the user will be shown a warning on the response.  I guess I have

 a hard time making this recommendation when instead I personally would

 recommend an IdP not advertise a HTTP endpoint if it has a HTTPS one.
 I think the reality is that anyone doing anything but testing with 
 OpenID really should be using SSL, though certainly also don't believe

 that 100% of IdPs and RPs will do so.

 Thoughts?

 --David




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


RE: OpenID Authentication 2.0 Pre-Draft 11 (Take 2)

2006-11-07 Thread Recordon, David
Thanks!  I remember you mentioning that before though I missed it.
Revision 93 corrects it.

Thanks,
--David 

-Original Message-
From: Johannes Berg [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 2:07 PM
To: Recordon, David
Subject: Re: OpenID Authentication 2.0 Pre-Draft 11 (Take 2)

On Tue, 2006-11-07 at 12:31 -0800, Recordon, David wrote:
 (codepoint 10, /n)

Maybe I shouldn't even be pointing this out but I think \n was
intended here?

johannes


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


Making return_to Optional

2006-11-06 Thread Recordon, David
From the call last week and the proposal at
http://openid.net/pipermail/specs/2006-October/000430.html, return_to is
not an optional parameter in the authentication request.  The idea being
that a RP not sending it signals the IdP to not redirect the user back;
rather an extension will be doing something useful.  I've checked in
this change, though would like it reviewed since I am not completely
happy with all the wording.

http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5
[EMAIL PROTECTED]compare
[EMAIL PROTECTED]ma
nualorder=1

Thanks,
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


IdP vs OP (WAS: RE: Editors Conference Call)

2006-11-06 Thread Recordon, David
I see both sides of this discussion.  I think John is correct that the
role of an OP really is not that different than that of SAML's IdP.  The
difference comes down to the trust model.  I certainly think reputation
networks will exist which rate OPs, RPs, users, etc and will ultimately
be needed for a technologies with promiscuous trust models to thrive
in a large scale.

I guess reading more of this is making me question if renaming IdP
really is the best thing to do in OpenID.  I think if anything we all,
as a larger community, should be working to bring OpenID and SAML closer
together versus driving them further apart.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Wednesday, November 01, 2006 2:20 PM
To: John Kemp
Cc: specs@openid.net
Subject: Re: Editors Conference Call


On 1-Nov-06, at 12:28 PM, John Kemp wrote:
 OK. Just checking. So an IdP/OP can choose whether or not to trust a 
 particular RP, based on some out-of-ban criteria. And an RP can choose

 whether or not to trust the assertions of a particular IdP/OP? OK 
 good.

Technically possible, yes for the RP to decide on an IdP/OP.
Currently, there is no verified RP identity, so the IdP/OP cannot make
that decision.

 I have not had a chance to wade into that discussion.

 I'd highly recommend it when you get the chance.

in my queue :)



 I suspect the latter case will be unlikely, if OpenID is to be 
 successful.

 And I do not. And that is the big driver why it should be OP instead 
 of IdP.

 I think what you're trying to say is that OpenID won't depend on 
 static trust relationships (like business contracts) between RPs and 
 IdP/ OPs - is that right? In which case, sure, I get that.

 But I do think OpenID will depend on there emerging a way of some RP 
 trusting (or not) some IdP (and vice-versa). Whitelists and blacklists

 seem like a scalable and dynamic way of doing that, and would seem to 
 be a reasonable way of minimizing the presence of rogue IdPs. Don't 
 take my word for it though - look at the discussion on [EMAIL PROTECTED]

I don't think there should be an OP reputation. I will wade into the
security@ list to discuss.


 asserted data.
 The OP is not verifying the accuracy of any of the attributes in 
 attribute exchange.

 A claim by my IdP/OP /might/ be a claim by a third-party, no? And if 
 the IdP/OP makes such a claim on my behalf (and is not under my direct

 control), won't it at least want to verify that the subject of the 
 claim is also the user whose identifier it asserted in OpenID 
 Authentication?

If the OP is making a separate claim about you, then it is not being an
OP at that time.
Perhaps I am missing your point here though.





 In OpenID Authentication, there is no trust relationship  
 requirement
 between the IdP and RP., and the only thing the IdP asserts is a
 binding between the user and an identifier (OpenID URL or i-name).

 And on what basis does the OP assert this binding to an RP?  
 Doesn't
 the OP typically authenticate that binding, or does it simply  
 take the
 users identifier on blind faith, and assert away?

 The OP authenticates the user (how the OP authenticates the user  
 is out
 of scope of the spec).

 OK - so the user probably maintains an account with the OP, very  
 much
 like a user would with an IdP? Unless the user runs her own OP.

The OP has a mechanism to determine which user it is interacting with.
If the user is running her own OP, then there is still an  
authentication process of some kind such as access to the machine.

-- 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: Making return_to Optional

2006-11-06 Thread Recordon, David
Yep... 

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 06, 2006 7:54 PM
To: Recordon, David; specs@openid.net
Subject: RE: Making return_to Optional

David, in the message below, I assume you meant to say return_to is NOW
an optional parameter... instead of return_to is NOT an optional
parameter That's the only way I can make sense of it.
Am I right?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Monday, November 06, 2006 11:10 AM
To: specs@openid.net
Subject: Making return_to Optional

From the call last week and the proposal at
http://openid.net/pipermail/specs/2006-October/000430.html, return_to is
not an optional parameter in the authentication request.  The idea being
that a RP not sending it signals the IdP to not redirect the user back;
rather an extension will be doing something useful.  I've checked in
this change, though would like it reviewed since I am not completely
happy with all the wording.

http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5
[EMAIL PROTECTED]compare
[EMAIL PROTECTED]ma
nualorder=1

Thanks,
--David
___
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: Making identities persistent?

2006-11-01 Thread Recordon, David
Pete,
While the transaction with the IdP is about the derived identifier (sort
of like that term actually), the RP uses the delegated identifier when
referencing the user.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Pete Rowley
Sent: Wednesday, November 01, 2006 10:53 AM
To: Rowan Kerr
Cc: specs@openid.net
Subject: Re: Making identities persistent?

Rowan Kerr wrote:
 On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote:
   
 I think you need the ability for a user to change his identifier at 
 the RP (as George notes below) and also at the IdP.
 

 Isn't this was already covered in the spec? You accomplish this by 
 creating an HTML page on some website you control with a http-equiv 
 meta tag in it that points to your IdP. Then you use your own url as 
 your Identity, even though ultimately the data is pulled from the IdP.

 So if you ever want to change IdP's you simply update your html page 
 with the new server. And your Identifier never needs to change.


   
Except that the spec specifies that it is the derived identifier of the
IdP that is used at the RP - which means a delegated identifier actually
isn't used as an identifier. That is not quite the same thing.

--
Pete

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


Editors Conference Call

2006-10-30 Thread Recordon, David
This morning Dick, Josh, and I got on Skype for 2.5 hours to try and
hash through all the remaining proposals.  Unfortunately Brad couldn't
join us, though I did talk to him about some of this stuff as well
beforehand.

 - Authentication Age will be developed as an extension due to questions
around what is the best way for it to work, what features does it need,
etc

 - The field setup_url will be removed from a checkid_immediate
response, rather the RP should fallback to a checkid_setup request to
complete the transaction.  It has been found that in the, albeit few,
implementations of checkid_immediate this is the behavior for the
setup_url anyway.

 - Support bare requests by having the field openid.return_to as
optional in checkid_* requests.  There is a worry of user's not knowing
when they'll be redirected back and when they won't, though that will
only be worked out by allowing this functionality.

 - Clarify that the openid.realm parameter should be used to uniquely
identifier relying parties

 - There are some places where it could be clear in step-by-step
instructions of what an IdP needs to do in various parts of the
protocol, like is done in section 12 for rp's.  Sxip will provide
pointers to where this clarity can be added.

 - Rename Identity Provider to OpenID Provider (IdP - OP) to add
clarity to the term since IdP has a very different meaning in the SAML
and WS-* worlds

 - The spec won't speak to what a RP should do if it has an identifier
like [EMAIL PROTECTED], worried about setting a confusing precedent of
allowing this form of identifier for discovery.  Users are used to
entering, example.com in their URL bar to goto the site, so entering
the same to login doesn't seem like to far of a stretch.  All of OpenID
has a user education challenge and this doesn't seem very different.

 - Spec will say in essence, RP's SHOULD give the text field a user
enters their OpenID Identifier a name attribute with a value of
'openid_identifier', though if a RP wishes to support rich clients it
MUST do so.

 - Dick will be writing a separate document discussing how RPs can
advertise services, logos, etc

 - There cannot be parameters with the same name, make sure spec says
this, we think it does.

 - Josh will be updating his delegation proposal patch to specify two
identifiers for all transactions.  This will create a consistent
paradigm when dealing with delegation or when not.

Goal is to have all of these changes made by end of day Wednesday.  I
doubt I've added enough detail in all places, so feel free to ask for
clarifications or wait to comment on the next draft.

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


RE: [security] [PROPOSAL] Adding More Color Around SSL Use

2006-10-27 Thread Recordon, David
This has now been checked in.
http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=73
sc=1

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Recordon, David
Sent: Thursday, October 26, 2006 1:48 PM
To: [EMAIL PROTECTED]; specs@openid.net
Cc: Martin Atkins
Subject: [security] [PROPOSAL] Adding More Color Around SSL Use

I'm planning to check in the following patch to the authentication spec
later today unless anyone has STRONG objections.  It says that SSL is
not REQUIRED, though comes as close to saying that it is that I think we
can.  Josh, Mart, and I believe this is a good middle position to take
on the matter.  We certainly believe any reputable IdP will correctly
use SSL, though there are cases (such as using OpenID Authentication
fully within your own trusted network) where it is not required.

--David

Index: openid-authentication.xml
===
--- openid-authentication.xml   (revision 68)
+++ openid-authentication.xml   (working copy)
@@ -2216,7 +2216,17 @@
   t
 In order to get protection from SSL, SSL must be used for
 all parts of the interaction, including interaction with
-the End User through the User Agent.
+the End User through the User Agent.  While the protocol
+   does not require SSL be used, its use is strongly
+   RECOMMENDED.  Current best practicies dictate that an IdP
+   SHOULD use SSL, with a certificate signed by a trusted
+   authority, to secure its service endpoint.  In addition,
+   SSL, with a certificate signed by a trusted authority,
+   SHOULD be used so that a Relying Party can fetch the
+   End User's URL in a secure manner.  Please keep in mind
+   that a Relying Party MAY decide to not complete, or even
+   begin, a transaction if SSL is not being correctly used
+   at these various endpoints.
   /t
 /section
   /section
___
security mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/security

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


[PROPOSAL] Adding More Color Around SSL Use

2006-10-26 Thread Recordon, David
I'm planning to check in the following patch to the authentication spec
later today unless anyone has STRONG objections.  It says that SSL is
not REQUIRED, though comes as close to saying that it is that I think we
can.  Josh, Mart, and I believe this is a good middle position to take
on the matter.  We certainly believe any reputable IdP will correctly
use SSL, though there are cases (such as using OpenID Authentication
fully within your own trusted network) where it is not required.

--David

Index: openid-authentication.xml
===
--- openid-authentication.xml   (revision 68)
+++ openid-authentication.xml   (working copy)
@@ -2216,7 +2216,17 @@
   t
 In order to get protection from SSL, SSL must be used for
 all parts of the interaction, including interaction with
-the End User through the User Agent.
+the End User through the User Agent.  While the protocol
+   does not require SSL be used, its use is strongly
+   RECOMMENDED.  Current best practicies dictate that an IdP
+   SHOULD use SSL, with a certificate signed by a trusted
+   authority, to secure its service endpoint.  In addition,
+   SSL, with a certificate signed by a trusted authority,
+   SHOULD be used so that a Relying Party can fetch the
+   End User's URL in a secure manner.  Please keep in mind
+   that a Relying Party MAY decide to not complete, or even
+   begin, a transaction if SSL is not being correctly used
+   at these various endpoints.
   /t
 /section
   /section
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Yet Another Delegation Thread

2006-10-24 Thread Recordon, David
What I wrote up doesn't allow a RP to have the information it needs to
maintain state is my understanding.

--David 

-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 24, 2006 5:12 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Yet Another Delegation Thread

Can we have those conversations on the list so that everyone understands
what the goals missed are?

I'd appreciate feedback on the revised proposal I emailed out and what
is missing from it.

-- Dick

On 24-Oct-06, at 3:45 PM, Recordon, David wrote:

 I honestly wasn't really putting it out as a proposal, rather 
 describing more of the different cases involved in all of this.  In 
 any case, talking this over more with Josh and Drummond it doesn't 
 actually accomplish all of the goals anyway.

 --David

 -Original Message-
 From: Dick Hardt [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 23, 2006 11:04 PM
 To: Drummond Reed
 Cc: Recordon, David; specs@openid.net
 Subject: Re: Yet Another Delegation Thread

 +1

 Glad to see that we have settled on one identifier parameter

 On 23-Oct-06, at 7:07 PM, Drummond Reed wrote:

 Here's another way to summarize the conclusions David and I reached 
 in

 our analysis today:

 1) In OpenID Authentication 1.1, if there is a difference between the

 identifier the user wants to assert to an RP and the identifier the 
 IdP wants to assert for the user (lets just call them ID1 and ID2), 
 then the mapping from ID1 to ID2 can only be handled by the RP (using

 the OpenID delegate feature).

 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP

 should also be able to handle the mapping between ID1 and ID2, and 
 indeed in the directed identity use case, the IdP MUST handle this 
 mapping.

 3) What David and I realized today is that there are even use cases 
 for BOTH the RP and IdP doing the mapping. In other words, even if an

 RP maps from
 ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to 
 prevent the IdP from mapping ID2 to ID3 and passing ID3 back to the 
 RP

 (as long as the RP verifies the IdP is authoritative for ID3).
 Example: I log into RP using one URI#1, which maps in my XRDS 
 document

 to another IdP- specific URI#2, and then when logging into my IdP it 
 reminds me that I previously used URI#3 at this RP, so I choose 
 URI#3.

 4) Therefore, as long as the protocol: a) REQUIRES the RP to do the 
 mapping from ID1 to ID2 if present in the HTML or XRDS (which gives 
 the user IdP-independent mapping if the user wants it), and b) ALLOWS

 the IdP to do the mapping from whatever identifier it receives
 (ID1 or

 ID2) to whatever identifier it wants to assert on behalf of the user 
 (ID3), then all use cases are supported. A user can take advantage of

 RP mapping, IdP mapping, or both.

 5) This flexibility means that, with the rules David wrote, only one 
 identifier parameter should be needed (although, as David suggests, a

 second parameter that is only a display hint from the RP to the IdP 
 might be a help
 -- and I would argue that it could work in the other direction as 
 well, but again only as a display hint.)

 =Drummond

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 Behalf Of Recordon, David
 Sent: Monday, October 23, 2006 6:09 PM
 To: specs@openid.net
 Subject: Yet Another Delegation Thread

 So been going through all of this up in Seattle with Drummond and 
 think I fully have my head around this.

 Thinking we have the following cases, which Draft 10 basically 
 already

 addresses.  In any of the responses, the IdP MAY return a differing 
 value for openid.identity than the RP requested.  This obviously 
 has varying degrees of usefulness depending on the specific 
 situation.
 See
 below for rules RP must follow to protect itself from bogus 
 assertions.

 1) IdP Registered
  a) Entered http://user.myidp.com   (IdP implicitly knows it
 owns)
 URI - http://myidp.com/server.cgi

  Request
 openid.identity - http://user.myidp.com
  Response
 openid.identity - http://user.myidp.com

  b) Entered http://user.example.com (IdP has an out of band 
 registration process where it verifies via discovery)
 URI - http://myidp.com/server.cgi

  Request
 openid.identity - http://user.example.com
  Response
 openid.identity - http://user.example.com

 2) Delegated (IdP knows nothing about what the user entered)
  a) Entered http://user.example.com
 URI - http://myidp.com/server.cgi
 OpenID:Delegate - http://user.myidp.com (IdP
 Controlled)

  Request
 openid.identity - http://user.myidp.com
  Response
 openid.identity - http://user.myidp.com

  b) Entered =user.example (or @2idi for Directed Identity case)
 URI - http://myidp.com/server.cgi

RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-10-22 Thread Recordon, David
While I'd certainly agree that a goal is letting anyone setup and IdP
and have it work on any RP, I see that as utopia.  The protocol should
certainly support that, as well as not do anything to actively thwart
it.  With that said, OpenID as a protocol can be used in cases where
this may not be desired.
 
I agree that the best way to look at this is by creating a distributed
trust/reputation network.  This thus allows a RP to intelligently make a
decision of if it should accept a given identifier, or the IdP it is
hosted on.  Right now I see this as needed to really bootstrap large
scale adoption.
 
Any word from Karmasphere about something like this Meng?
 
--David
 
P.S. Plain-text kills all fonts. :)



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kaliya Hamlin
Sent: Sunday, October 22, 2006 3:43 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style
Identifiers


For starters please don't use Comic Sans in professional correspondence.
it is very hard to read (or take seriously)
http://bancomicsans.com/home.html


On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:



It's more of a problem with how we can accept 3rd party OpenId
users at AOL (we as an RP). Obviously for simple use cases like leaving
comments on blogs it wouldn't really matter as long as the user is
identified by someone (and someone doing rate limiting or something else
to prevent spamming - otherwise I still can't see how it reduces spam
anyway) - but when we want to take it to the next level - provide more
services to these users (photos/calendar/etc.. ) we want to limit it to
only a few IDPs whom we trust. (due to both security and business
reasons).



This doesn't really work in the model.  The goal is to let anyone set up
their own OpenID and that basically across the OpenID universe it works.
You limiting it to only like verisign or other 'big' IdP's is not really
part of the vision of what we are trying to build.  Obviously behind
this whole network needs to be reputation for IdPs and individual OpenID
addresses.  


So this is the problem we are trying to figure out how we can
message the users that we support OpenIds from certain providers (say
Verisign PIP) but not from all. 



This is one way to approach it and I hope you don't do it this way
because it breaks what OpenID is about. 


Another area where we want some more clarification (if it
already exists) or support is about how we can have a persistent handler
(apart from URI) for a given user so it would help in cases when a
user's account gets reclaimed by someone else. 



ahh...that is where further reading of what i-names and i-numbers are
about would help.  Because there is another level of indirection built
in, when an i-name is reassigned the i-number below it is not.   This
helps users not have the 'reclaiming by someone else problem' when
depending on URLs. 







__

Identity Woman: Saving the world with user-centric identity. 
www.identitywoman.net


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


RE: Two Identifiers - no caching advantage

2006-10-22 Thread Recordon, David
  * Protocol has two distinct identifiers: public and IdP-local.
Relying 
 party manages delegation. IdP does not even know that the delegation
has 
 taken place and has no way to stop it happening [1]. RP now has to do 
 more work, but identifier portability now comes for free.
I'm much more in favor of that, though see the value in having the IdP
know the public identifier so that it can correctly prompt the user.

I think one identifier, with the IdP managing the entire relationship is
too much of an architectural jump from 1.1.  Take LiveJournal for
example, somehow I doubt we'd see delegation support in this case
anytime soon.

I think what is important is keeping the simplicity of delegation in
1.1, while cleaning up the metaphor and making it more user-friendly at
the same time.  Perfection is the enemy of the good.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Sunday, October 22, 2006 1:34 PM
To: specs@openid.net
Subject: Re: Two Identifiers - no caching advantage

Dick Hardt wrote:
 On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote:
 
 On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote:
 2) the RP does not verify the binding between the portable 
 identifier and the IdP-specific identifier in the response.
   to the one the attacker controls and the IdP has mapped
 This is the part where I think you're wrong. The RP MUST verify that 
 binding, whether it is by keeping state, self-signing the request 
 (which gets passed through to the response) or doing discovery again.
 
 I agree the RP SHOULD do that. The proposal does not specify that.
 I thought we had that conversation. I have not looked at the patch 
 that you sent. Perhaps you address the issue there.
 
 My point though is: why have the RP bind the IdP-specific identifier 
 and the public identifier? Why not let the IdP be responsible for
this?
 
 In 1.x when the IdP was not aware of the public identifier, then the 
 RP had to do the binding. Now that the IdP is aware of the public 
 identifier, it would be simpler and logical for the IdP to be 
 responsible for the binding. It is doing it anyway.
 
 All the RP wants is which public identifier is the user, and is the 
 IdP authoritative for it.
 

If delegation is going to require cooperation from the IdP anyway, 
there's no longer any value in having the distinction between a public 
identifier and an IdP-local identifier. The hypothetical IdP 
IdP-tastic can just store a relationship between 
http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's

no need for http://mart.idp-tastic.com/ anymore, and with that gone 
delegation is no longer useful: the public identifier, whatever it might

be, is the only identifier.

Any disadvantages to uniting the public identifier and the IdP 
identifier are also disadvantages of having the IdP do the binding as 
you describe. For simplicity's sake, I'm currently only willing to vote 
positively for one of the following scenarios:

* Have only one identifer in the protocol. Remove delegation entirely. 
IdP maintains relationships between arbitrary identifiers and its local 
user accounts. IdP no longer needs to issue its own identifiers, though 
it can if desired. This makes life simpler for RPs, but has the risk 
that delegation would become an IdP premium feature, which may hurt 
users in the long term.

* Protocol has two distinct identifiers: public and IdP-local. Relying 
party manages delegation. IdP does not even know that the delegation has

taken place and has no way to stop it happening [1]. RP now has to do 
more work, but identifier portability now comes for free.

Having the IdP deal with the public identifier while still keeping the 
IdP-local identifier (and thus delegation) is, it seems to to me, 
muddled nonsense; the whole purpose of delegation was to make these 
identifiers distinct.


[1] Conceivably a mischievous IdP could make use of knowledge of how 
particular RPs round-trip their delegation state to block it, but that 
would be an arms race in the RP's favour rather than a designed-in 
mechanism for detecting delegation.

___
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: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)

2006-10-21 Thread Recordon, David
Title: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)






Feel free to write a patch for that section. :)

--David


-Original Message-
From:  Dick Hardt [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 21, 2006 06:21 PM Pacific Standard Time
To: Recordon, David
Cc: Josh Hoyt; specs@openid.net
Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)

Missed that section. It is not clear what the return_to URL is though.

The return_to URL may not be the same thing as the action URL from
the login form. What we wanted was the action URL since we want to
POST openid_identifier=OpenID URI to that URL. This would be a
different message then the indirect response message from the IdP
which is signed etc.

I think this is the right direction, we just need to clarify more
what that end point is.

-- Dick


On 19-Oct-06, at 11:21 AM, Recordon, David wrote:

 Which is still described in the latest draft, see
 http://openid.net/specs/openid-authentication-2_0-10.html#anchor42.

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
 Behalf Of Josh Hoyt
 Sent: Thursday, October 19, 2006 1:24 PM
 To: Dick Hardt
 Cc: specs@openid.net
 Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)

 On 10/19/06, Dick Hardt [EMAIL PROTECTED] wrote:
 I like your proposal. I would tweak the name:

 link rel=openid.entry href="" href="http://my.rp.com/openid/blah.cgi">http://my.rp.com/openid/blah.cgi

 This is what Yadis was designed for. Since OpenID already requires
 Yadis, this should be implemented as a Service entry in the Yadis
 document for any page on which you want that information.

 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


RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-10-20 Thread Recordon, David
Yes, potentially.  It is a bit of a hybrid approach I guess.

--David 

-Original Message-
From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 20, 2006 12:59 PM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style
Identifiers

# The thing is they aren't really giving them their email address.
# Rather an identifier which looks like an email address to a user and #
in some cases may also be an email address.

Isn't that likely to create a lot of confusion?

--
  Jonathan Daugherty
  JanRain, Inc.

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


  1   2   >