Chris,
I think you may have me mistaken for somebody else on the list (DR is also
David Recordon). I'm a big fan of IdP-initiated login and privacy protection
in OpenID.
However as much as I think that's an important use case, there's also many
use cases around using a public, "omnidirectional" i
My votes on three issues (0 on everything else):
Consolidated Delegation Proposal
* -1 on status quo (draft 10)
* +1 on two-identifier
Change default session type
* +1
Bare request
* +1
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rec
Hi Drummond,
DR> ... if there is any record at all of any association between these
DR> two identities, ...
double-blind anonymous authentication solves this problem. The RP
knows nothing more about you besides:
A) you're authenticated, and/or
B) you've been here before (eg: have signed up for a
The security profiles drafts that we published a few weeks
back have been uploaded [1-2] to openid.net
These are works in progress, so feel free to chime in.
Hans
[1] http://openid.net/specs/
openid-authentication-2_0-security-profiles-01.txt
[2] http://openid.net/specs/
openid-
On Mon, 16 Oct 2006 15:24:25 -0700
"Recordon, David" <[EMAIL PROTECTED]> wrote:
>
> Change default session type
> * +1
I'm not sure what changing the default buys us. The RP still has to create a
public modulus and send it in the request in order to use DH, so there's still
a positive action
I'm happy to drop it, just wanted to throw it out there.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
Hoyt
Sent: Monday, October 16, 2006 3:48 PM
To: Marius Scurtescu
Cc: Recordon, David; specs@openid.net
Subject: Re: Notes From Draft 10
On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> > Just so that there is an obvious one way to do it, so that it's easier
> > to get right, if I understand David's motivation. It's also easier to
> > make clear in the spec.
>
> If ordering is not important then you are guaranteed to get i
I want to avoid the
"wait-I-thought-we-decided-something-else" or
"ahh-yes-seems-we-forgot-it-had-an-impact-there"
delays . . .
Spec work gain tremendously by unambiguous up-front
definitions of what *exactly* is voted on.
A good way to do this is to force the vote to be
on an explici
On 10/16/06, Hans Granqvist <[EMAIL PROTECTED]> wrote:
> What's the security benefit of forcing the protocol to use a
> specific order?
I don't know of any security benefit of using a specific order. I'm
pretty certain that this proposal came about to make the spec easier
to read and implement.
>
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote:
> On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> Sorting of unicode strings while not terrible hard it is not trivial
>> either. Why bother? The list of signed fields gives an explicit
>> ordering, this is good enough IMO.
>
> Sorting by UTF-
Marius Scurtescu wrote:
> On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote:
>
>
>>On 10/16/06, Recordon, David <[EMAIL PROTECTED]> wrote:
>>
>>>6.1 Signed List Algorithm
>>
>>[...]
>>
>>>I'm thinking it would make sense to
>>>change this algorithm to first alphabetically sort the arguments
>>>to make
And here are my votes:
Request nonce and name
* Take no action
Authentication age
* -1, write as an extension first
Remove setup_url
* 0 for removing, +1 for asking feedback from implementers
Consolidated Delegation Proposal
* -1 on status quo (draft 10)
* 0 on single-identifier
* +1 on
On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> Sorting of unicode strings while not terrible hard it is not trivial
> either. Why bother? The list of signed fields gives an explicit
> ordering, this is good enough IMO.
Sorting by UTF-8-encoded octet sequence is easy.
> Why would be an
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote:
> On 10/16/06, Recordon, David <[EMAIL PROTECTED]> wrote:
>> 6.1 Signed List Algorithm
> [...]
>> I'm thinking it would make sense to
>> change this algorithm to first alphabetically sort the arguments
>> to make
>> it very clear in terms of ordering.
>
On 10/16/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> 6.1 Signed List Algorithm
[...]
> I'm thinking it would make sense to
> change this algorithm to first alphabetically sort the arguments to make
> it very clear in terms of ordering.
I think it's a good idea to say that the signed list MUST
+1. "Trust is not a boolean." Martin, that's very quotable. Can I attribute
it to you?
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Martin Atkins
Sent: Monday, October 16, 2006 12:25 PM
To: specs@openid.net
Subject: Re: Identifier portabilit
On 16-Oct-06, at 2:01 PM, Josh Hoyt wrote:
> On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> In this case you are better off opening a separate account with this
>> or some other IdP. The current delegation model will not protect you
>> at all. The delegate tag is in a publicly accessi
While I've already incorporated many of the things I found in draft 9
into 10, there were a few things which I didn't either have the right
answer to or feel that I could make the change on my own. I tried
reading through the draft as if I was reading it for the first time.
4.2 Integer Representa
On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> In this case you are better off opening a separate account with this
> or some other IdP. The current delegation model will not protect you
> at all. The delegate tag is in a publicly accessible Yadis document.
>
> I agree that anonymity is
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote:
> Chris Drake wrote:
>>
>> There seem to be a lot of people on this list who want to hate and
>> loathe the IdP, and grant all power to the RP. I do not understand
>> this reasoning: our users will select the IdP they trust and like,
>> then they w
Chris Drake wrote:
>
> There seem to be a lot of people on this list who want to hate and
> loathe the IdP, and grant all power to the RP. I do not understand
> this reasoning: our users will select the IdP they trust and like,
> then they will be using a multitude of possibly hostile RPs
> ther
Here are my reactions to what's outstanding:
On 10/15/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> * Request Nonce and Name
> - Has been partially implemented, openid.nonce ->
> openid.response_nonce, no agreement on the need of a request nonce
> specifically, rather discussion has evolved in
Chris Drake wrote:
> There seem to be a lot of people on this list who want to hate and
> loathe the IdP, and grant all power to the RP. I do not understand
> this reasoning: our users will select the IdP they trust and like,
> then they will be using a multitude of possibly hostile RPs
> thereaf
On 10/14/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> Also note that URL parameters are not secured by TLS in HTTPS.
>
> -- Dick
URL parameters are sent with the path in the GET line of the HTTP
request after the TLS handshake, so URL parameters ARE secured.
--
Grant Monroe
JanRain, Inc.
___
Right, I'd agree with that. This would just be the first case where the
Auth spec doesn't provide at least one service type for the file. In
any case, adding the ability seems important.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atk
Dick Hardt wrote:
> Given that the spec uses the word identifier throughout, it would
> make sense that the parameter would be called that.
>
> Perhaps in changing what the parameter contains, we can rename it,
> and keep openid.identity for backward compatibility?
>
I think this a good idea
Recordon, David wrote:
>
> I'm torn if this parameter should be added to the spec at this time or
> not. Adding the parameter is conceptually simple, though I don't think
> there is agreement on what the RP should be publishing in their Yadis
> file. There is the section
> http://openid.net/spec
Drummond Reed wrote:
> Suggestion: sidestep the issue completely and in the spec -- and everywhere
> else -- just call it OpenID provider. It's a simple concatenation of
> "OpenID" and "service provider", so everyone gets it, but nobody will
> associate it with SAML or federation or anything else.
Dick Hardt wrote:
>
> I don't think we actually need to have a specific name when talking
> to users. it is a site that supports OpenID.
I agree.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
29 matches
Mail list logo
