I am not sure what advantage there is to using other verbs. Would
you elaborate on the advantages?
I'm not sure I understand this question. Are you asking why
standard HTTP has verbs other than POST? Or why things WebDav
increased the list further?
no, I know why they have the verbs
On 25-Sep-06, at 10:59 AM, Johannes Ernst wrote:
I don't understand why we should make it hard (impossible?) to
use OpenID authentication with verbs other than POST.
How would you propose OpenID use the other verbs?
If there a mechanism to authenticate an HTTP GET request (as OpenID
On 25-Sep-06, at 2:59 PM, Johannes Ernst wrote:
I thought we had consensus that Drummond and I owned the
vocabularies/ontologies/schema/whatever-we-call-it action item?
nope
We've come up with something rather beautiful (I think ;-)) that
avoids a gap between XDI, LID and DIX (or
On 25-Sep-06, at 5:31 PM, Brad Fitzpatrick wrote:
On Mon, 25 Sep 2006, Dick Hardt wrote:
If this is the case (David Fuelling's summary) then backwards
compatibility of the spec is not needed. If backwards compatibility
is required, then the 2.0 spec can just say that 1.1 must also
On 25-Sep-06, at 5:41 PM, Brad Fitzpatrick wrote:
On Mon, 25 Sep 2006, Dick Hardt wrote:
So you would not support inames,
LiveJournal would not.
Yadis,
We already do! And will continue to improve that as spec changes.
nonces,
Already do, via the Net::OpenID::* modules, which do
On 26-Sep-06, at 3:58 PM, Recordon, David wrote:
I think that is slightly different from what Gerv was referring to.
With Simple Registration, there is nothing stopping a relying party
from
requesting the email address with every authentication request. Most
implementations however
Hi Kevin
Some background on where support for existing form handlers came from:
The use case is for registration pages to be able to accept a post
from an IdP without being modified. The registration processing would
of course not be performing any signature checks and would not need
to be
On 28-Sep-06, at 5:28 AM, Gervase Markham wrote:
Dick Hardt wrote:
Gerv: did this address your use case?
Yes, I think this provides enough flexibility in terms of having the
target site get updated data. I just wanted not to have to update
every
site when my details change.
Although I
On 28-Sep-06, at 3:18 AM, Martin Atkins wrote:
Josh Hoyt wrote:
If that weren't so, then why is there the openid. prefix to the
parameters in some of the messages?
The reason that the parameters have openid. at the beginning is so
that it is clear that they are part of the OpenID protocol
On 29-Sep-06, at 3:34 PM, Gervase Markham wrote:
Dick Hardt wrote:
check out
http://openid.net/specs/openid-attribute-properties-
list-1_0-01.html
Ooh, yuk:
http://openid.net/schema/contact/web/Linkedin
Surely:
http://openid.net/schema/contact/web/com.linkedin
? That makes
Motivating Use Case
It is useful for an RP to know that a response to a request has
already been processed and is not stale.
A standard way to do this that can be incorporated into the Libraries
would simplify things for the RP implementor
Proposed Implementation
Motivating Use Case:
Different RPs will require different amounts of certainty about the
user, and at times will have different requirements depending on what
the user is doing. Eg. from existing web applications today. There is
little concern when the user is
Motivating Use Case
The IdP would like to allow the user to click a link on the IdP to
login to an RP. This requires a bare response to be able to be sent.
A Trusted Party, acting as an RP would like to store a value at the
IdP, but does not need the IdP to send
+1 assuming that we solve the multivalue parameter issue somehow. See:
http://openid.net/pipermail/specs/2006-September/000139.html
Agree with security issue. Motivator for it was support for multiple
parameters of same name.
-- Dick
On 29-Sep-06, at 2:47 PM, Granqvist, Hans wrote:
Kevin, thanks for the well articulated argument.
I do see this as something that is completely within the End Users
control, and if the End User chose to ignore it, then that is their
choice.
The use case is that for convenience, a site wants to let the user do
certain functions without
I have finally got up on this thread and don't see the value of the
openid.display parameter.
The RP does not know who the user is when the user is using OpenID to
login, since that is why the RP is using OpenID, to find out who the
user is.
Having the user type in another parameter just
+1
Allows us to easily have a request_nonce now or in the future and
have clarity on what is what
-- Dick
On 9-Oct-06, at 2:19 PM, Recordon, David wrote:
Judging from a lack of responses, I'm guessing people don't really
care.
Is this a correct assessment?
I'm +1 to this to add
On 6-Oct-06, at 11:14 AM, Chris Drake wrote:
An ***IdP*** can *initiate* the OpenID login with the RP using
openid:Token.
How the User arrived at the RP with this token is not the concern of
the RP. (could be javascript, browser plugins, participating IdP
helper CGIs, or even the RP
an identifier to
persist is
the directed identity case (Case 1). In that case, the RP does not
send
openid.rpuserid, but instead receives it back in the response from
IdP.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 2:21 PM
to just address an XRI user by an internal account name and not the
i-name
synonym they used at the RP -- then we can drop openid.display.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 2:19 PM
To: Drummond Reed
Cc: 'Josh Hoyt
I'll start off with a couple new definitions so that we are not hung
up on what terms mean:
supplied_identifier := what the user types into the RP's form
verified_identifier := the identifier that the IdP says the user is
When looking at the OpenID protocol, the openid.identity sent from
the
I am really unclear on why do we need both openid.identity and
openid.rpuserid?
-- Dick
On 10-Oct-06, at 12:47 AM, Drummond Reed wrote:
David,
Based on feedback, I've backed openid.display out of the consolidated
proposal at http://www.lifewiki.net/openid/
On 10-Oct-06, at 11:26 AM, Martin Atkins wrote:
Josh Hoyt wrote:
On 10/10/06, Martin Atkins wrote:
Does the IdP really need to know what URL I gave to the RP?
Earlier versions handled this adequately by the library including
implementer-defined variables in the return_to URL, which allows
On 10-Oct-06, at 11:44 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
I don't think the delegate needs to be moved. Please see
http://openid.net/pipermail/specs/2006-October/000310.html
If I understand it correctly, this is identical to my original
proposal[1
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
RP user id is the identifier by which the relying party knows the
user.
This is the one that the user gave the RP?
For URL identifiers, it is the supplied identifer, normalized, after
following
On 10-Oct-06, at 11:58 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
My proposal was pretty much your proposal with a couple tweaks
(sorry, I should have listed these to make it clearer)
- the IdP can return a different identity then the one the RP sent
over
I
On 10-Oct-06, at 12:48 PM, Drummond Reed wrote:
Drummond wrote:
If we've got it wrong there, and there is a way to do all of this
with one
parameter, by all means do explain and we can finally close this
issue.
Dick wrote:
I thought I did explain it. :-)
I will explain it again in a
On 10-Oct-06, at 11:54 AM, Josh Hoyt wrote:
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
RP user id is the identifier by which the relying party knows the
user.
This is the one that the user gave the RP?
For URL identifiers, it is the supplied identifer, normalized, after
following
+1
Well said Chris.
On 10-Oct-06, at 11:22 PM, Chris Drake wrote:
This is backwards: Users have already chosen the IdP whom they trust
to look after their identity and privacy: and except for the unlikely
double-blind scenarios, no user will want to hide RP info and usage
from their own
This draft has good discussion about what a good protocol is and the
issues in extending protocols:
http://www.ietf.org/internet-drafts/draft-carpenter-extension-
recs-00.txt
-- Dick
___
specs mailing list
specs@openid.net
On 10-Oct-06, at 2:08 PM, Drummond Reed wrote:
On 10/10/06, Dick Hardt wrote:
[openid.rpuserid is the identifier] that the user gave the RP?
Josh Hoyt wrote:
For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen
On 13-Oct-06, at 7:45 PM, Drummond Reed wrote:
And despite all the but it can't be stateless without two!
noise, it
actually can: you put the portable identifier in the return_to
URL and
verify it again when you get the signature back from the IdP.
That is,
verify the
On 14-Oct-06, at 7:28 AM, Chris Drake wrote:
JH Where is power being granted to the RP? It has pretty much none.
JH It *does* have responsibility, but only as much as is necessary to
JH make the protocol work.
If RPs are allowed to build up linked portfolios of everyones
identifiers, they
Also note that URL parameters are not secured by TLS in HTTPS.
-- Dick
On 13-Oct-06, at 3:57 AM, Chris Drake wrote:
Hi All,
Just so everyone remembers: GET encoded http://; URLs usually
appear en-mass in public lists (from proxy cache logs). If you don't
want to POST data anyplace,
On 14-Oct-06, at 7:36 PM, Recordon, David wrote:
Dick,
While it is true that the IdP should still check that they are bound,
except in the case when it is directly authoritative for both, the RP
should provide the IdP with what the user entered as a hint to what
claim the End User is
Authentication 1.1
David Recordon, Brad Fitzpatrick, May 2006
http://openid.net/specs/openid-authentication-1_1.html
.. [3] [PROPOSAL] bare response / bare request
Dick Hardt, 30 September 2006
http://openid.net/pipermail/specs/2006-September/000142.html
.. [4
Motivating Use Case:
When an RP is storing attributes at an IdP and does not want to
authenticate the user, the RP may want the user to remain at the IdP.
Other extensions may want similar functionality
Proposal:
A missing openid.return_to is NOT an error.
Affects:
5.2.3
10.1
Currently there is no method for the IdP to learn anything about the
RP. As a path for extensibility, would anyone have a problem with
having an optional parameter in the AuthN Request for the location of
the RP's Yadis document?
-- Dick
___
Clarification:
auth_age allows an RP to specify how long it has been since the IdP
has authenticated the user. The use case of this is for sites that
have different auth_age requirements for different sections of the
site. For example, amazon.com lets me browse around the site with an
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?
-- Dick
an extension to the protocol is needed.
On Oct 14, 2006, at 22:39, Dick Hardt wrote:
Currently there is no method for the IdP to learn anything about the
RP. As a path for extensibility, would anyone have a problem with
having an optional parameter in the AuthN Request for the location of
the RP's
for obtaining the XRDS
DR file, given the return_to URL.
DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:
I assume you are referring to the return_to URL?
Current libraries add all kinds of parameters to that URL, would
you be suggesting that the IdP does a GET on the return_to URL with
content-type
I think we should be open (pun intended) to making changes.
I really like the OpenID Provider - shortens to OP, and is very
specific on what it does.
I have always found IdP to be a misnomer, and have mentioned it in
the past.
Now we have a great candidate, that provides more clarity, and it
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 will be
On 13-Oct-06, at 3:43 PM, Josh Hoyt wrote:
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
The IdP is issuing a signed assertion about these identifiers, I
would assume the IdP to check the link between these identifiers.
Sending two identifiers does not *prevent* the IdP from
On 16-Oct-06, at 11:21 AM, Josh Hoyt wrote:
* Bare Request
- Proposed, no discussion yet.
-0 (YAGNI)
Sorry, I don't know what YAGNI means ...
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
On 15-Oct-06, at 7:25 PM, Recordon, David wrote:
Hi Chris,
The rush is that 2.0 has been in a drafting phase for almost six
months
now, with draft five being posted at the end of June. While we
certainly can continue taking the time to make everyone happy, we
ultimately will never have
and there seems to be general consensus,
excluding Sxip, that the protocol should have two parameters.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Tuesday, October 17, 2006 5:24 PM
To: Dick Hardt
Cc: specs@openid.net
Hey Lists
We realized in a meeting today that we had talked to some people in
the community, but had never made a formal statement.
Sxip is writing and will be releasing Java and Perl libraries for
OpenID 2.0 under an Apache license.
You should see them shortly after the spec is finished,
I would like to use different IdPs for my vanity URL, blame.ca. In an
OpenID 2.0 world, I can provide either of my IdP URLs to the RP and
then select blame.ca and login.
Does this work? What having two openid.server tags suffice? How would
the RP know which delegate tag goes with which IdP?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jonathan Daugherty
Sent: Wednesday, October 18, 2006 2:33 PM
To: Dick Hardt
Cc: specs@openid.net
Subject: Re: PROPOSAL: OpenID Form Clarification (A.4)
# Proposal
#
# Modify 8.1 to:
# ...
#
# The form
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Wednesday, October 18, 2006 3:27 AM
To: Drummond Reed
Cc: specs@openid.net
Subject: Re: Question: multiple IdPs?
Thanks Drummond, but what if I am using HTML-based discovery? (that is
what I am
not follow this recommendation
then
a rich client should treat it as not being a relying party.
--David
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 11:35 PM
To: Recordon, David
Cc: Jonathan Daugherty; specs@openid.net
Subject: Re
described. In any case, it is surprising what
people can do when following Internet tutorials.
--David
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 12:01 AM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: Question
. :-\
--David
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 12:08 AM
To: Recordon, David
Cc: Jonathan Daugherty; specs@openid.net
Subject: Re: PROPOSAL: OpenID Form Clarification (A.4)
Please see the RFC. SHOULD is used if there is a valid
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 12:12 AM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: Question: multiple IdPs?
Agreed that it is a power user that wants multiple IdPs, but per
Josh's
email
Hey Drummond
In reviewing:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
...
Summary of Motivations
4. Enable RPs to take advantage of XRI CanonicalDs to protect End-
Users from ever having their Portable Identifier reassigned (and thus
their identity taken over).
On 19-Oct-06, at 8:40 AM, Drummond Reed wrote:
I agree the scenarios Dick proposes here make sense. However if the
IdP can
change an identifier parameter, it should be openid.portable,
since: a)
that's the one the RP is going to store, and b) that's the one the
IdP MUST
return with
On 19-Oct-06, at 11:18 AM, Josh Hoyt wrote:
On 10/19/06, Dick Hardt [EMAIL PROTECTED] wrote:
sigh reread the attack. The portable identifier and the IdP do
match.
In fact, this makes me think of an attack that *would* succeed if the
IdP-specific identifer was not in the response:
when
On 19-Oct-06, at 11:12 AM, Josh Hoyt wrote:
On 10/19/06, Dick Hardt [EMAIL PROTECTED] wrote:
Your attack fails.
sigh reread the attack. The portable identifier and the IdP do
match.
No the identifiers do not.
They do. The attacker goes to the RP and enters my blog URL. The
attacker
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
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
).
http://www.w3.org/TR/P3P/#ref_syntax
Are you proposing the same thing for OpenID login?
(Kewl!)
=Drummond
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Dick Hardt
Sent: Thursday, October 19, 2006 12:53 AM
To: Martin Atkins
Cc: specs@openid.net
On 20-Oct-06, at 12:17 PM, John Panzer wrote:
Kaliya * wrote on 10/20/2006, 11:57 AM:
I think it is a terrible idea.
1) If you put something out into the market that looks like an e-
mail it will be used like an e-mail. I have personal experience
with this.
I had a AIM handle for the
On 19-Oct-06, at 10:24 AM, Martin Atkins wrote:
Dick Hardt wrote:
Agreed that it is desirable to have multiple RP endpoints for an RP.
Does openid.realm then uniquely identify an RP? ie. no other RP will
use the same Realm?
I'd say that if two endpoints are within the same realm
On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote:
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
Kaliya: The easy solution is to have your email program turn all
responses to plain
On 22-Oct-06, 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
On 22-Oct-06, at 12:55 PM, Recordon, David wrote:
In the case where there are two realms:
http://*.livejournal.com
http://dick.livejournal.com
I would have my IdP treat them as separate relying parties. If the RP
directly decided to set the realm differently, then I'd imagine the
On 22-Oct-06, at 5:05 PM, George Fletcher wrote:
Dick Hardt wrote:
What is different with OpenID vs email is that there is certainty
that the user actually is the user.
I'm a little confused. How is there certainty that the user
actually is the user? The viability of the identifier
On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
Dick Hardt wrote:
With OpenID, there is a presumption the user has selected a trust
worthy IdP that will only present the user's identifiers when it
really is the user.
Doesn't this imply that both the user and RP have to know which IdP's
On 22-Oct-06, at 9:04 PM, George Fletcher wrote:
Dick Hardt wrote:
On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
Dick Hardt wrote:
With OpenID, there is a presumption the user has selected a trust
worthy IdP that will only present the user's identifiers when it
really is the user
-1 for these reasons:
Complexity: There is no reason for the RP to be managing the binding
between the IdP and the portable identifier. Both the IdP and the RP
are verifying this. There is no extra security, and more things to go
wrong in an implementation.
Privacy: There is no reason for
Hello List
I have written up what I think are the requirements for identifiers
so that we can see if we agree to those. If so, then the proposal
revision I have below may be an acceptable solution that keeps things
simple and provides backwards compatibility.
Sorry that we are still having
On 23-Oct-06, at 12:27 AM, Martin Atkins wrote:
Dick Hardt wrote:
Complexity: There is no reason for the RP to be managing the binding
between the IdP and the portable identifier. Both the IdP and the RP
are verifying this. There is no extra security, and more things to go
wrong
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
-
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
Thanks for the explanation Drummond. I think we need a con call on
this topic alone ... :-)
On 24-Oct-06, at 6:16 PM, Drummond Reed wrote:
* But in our discussion today, Josh and David and I boiled down the
fundamental problem with the single identifier on the wire
solutions: as
long as
on their telecon (I agree this issue could consume
an entire
call). I doubt I can add anything more here, so I'll just wish you all
godspeed on the call.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 24, 2006 10:07 PM
To: Drummond Reed
Cc
On 25-Oct-06, at 10:36 AM, Josh Hoyt wrote:
On 10/25/06, Dick Hardt [EMAIL PROTECTED] wrote:
2) Since the RP has to do discovery on the Claimed Identifier
anyway, if it
discovers a mapping between the Claimed Identifier and an IdP-
Specific
Identifier, the RP can send the IdP-Specific
On 25-Oct-06, at 12:43 PM, Josh Hoyt wrote:
The primary reasons that I think it's useful to send the IdP-specific
identifer as well:
1. The IdP is not *responsible for* doing discovery, so:
* It's possible to be more efficient, since discovery is not
duplicated by the IdP and RP.
On 26-Oct-06, at 8:27 AM, Josh Hoyt wrote:
On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote:
* If the IdP-specific identifier is not checked by the relying
party's discovery, the IdP MUST do discovery on every request to
ensure that it's not making an assertion based on stale
Thanks David! ;-)
Patrick, as you point out, Identity Provider is a well understood
term in SAML and WS-*. Here is the definition from SAML 2.0 [1]
Identity Provider: A kind of service provider that creates,
maintains, and manages
identity information for principals and provides principal
On 6-Nov-06, at 11:46 AM, Recordon, David wrote:
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
On 6-Nov-06, at 10:25 PM, Drummond Reed wrote:
Why? It's because in a user-centric identity, the OP is fundamentally
NOT (that enough stars for you? ;-) the provider of
anyone's
identity.
It is providing the OpenID protocol service though, correct?
Not sure if you are
On 7-Nov-06, at 7:59 AM, John Kemp wrote:
Dick Hardt wrote:
On 6-Nov-06, at 11:46 AM, Recordon, David wrote:
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
://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
On 7-Nov-06, at 8:17 AM, John Kemp wrote:
Dick Hardt wrote:
On 7-Nov-06, at 7:59 AM, John Kemp wrote:
I don't believe that trust is a differentiator between SAML
specifications and OpenID Authentication specifications.
It is AFAICT, in both cases, simply out of scope.
I should have
]
On Behalf
Of Recordon, David
Sent: Monday, November 06, 2006 11:46 AM
To: Dick Hardt; John Kemp; Patrick Harding
Cc: specs@openid.net
Subject: IdP vs OP (WAS: RE: Editors Conference Call)
I see both sides of this discussion. I think John is correct
that the
role of an OP really
On 7-Nov-06, at 3:42 PM, Recordon, David wrote:
So I know I said no more proposals like a month ago, but this one
helps
from a security perspective around the signature on the response.
Currently the response must have return_to, response_nonce and
then
disco_id and identity if they
I agree with Johannes here. DNS is not user accessible (for good reason)
Documents on a web server are relatively more accessible.
wrt. DNS, I think DNSSEC could have a significant role in providing
server to server discovery, specifically of key key material.
-- Dick
On 8-Nov-06, at 8:00 PM,
On 10-Nov-06, at 7:20 AM, David Fuelling wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Jonathan Daugherty
# I think that all this discussion about email userid is moving us
off
# track. My original proposal was that the email
On 9-Nov-06, at 7:45 AM, Rowan Kerr wrote:
On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote:
-Original Message-
From: Recordon, David
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
Hi Adam
The switch from GET to POST was made so that we were not constrained
by the URL parameter payload limit.
As you point out, HTTP headers can be used for moving messages as
well, but there was no clear mechanism to do that without modifying
all the widely available browsers.
I think
On 17-Nov-06, at 10:38 AM, John Kemp wrote:
Dick Hardt wrote:
On 16-Nov-06, at 11:41 PM, Matt Pelletier wrote:
On Nov 17, 2006, at 1:24 AM, Dick Hardt wrote:
Hi John
So that a message can be more then 2K of data.
Is it possible to update the language so 1) we don't deprecate HTTP
On 19-Nov-06, at 3:08 PM, Adam Nelson wrote:
Great start on the Wiki. Note that there are some efforts in IETF for
enhancing what can be done at the TLS layer for authentication which
would enable the same mechanism to be used not only for HTTP, but for
SMTP, POP3, IMAP ...
Hmm, that's
Below is a summary of draft specifications for OpenIDAttribute
Exchange, Attribute Types and Attribute Metadata.
I will check them into SVN real-soon-now and hopefully David will
have them linked off the spec site.
HTML versions will be posted as separate emails for those in the US
unable to
data-1.0]
Hardt, D., Identity Attribute Metadata, October2006 (TXT, HTML).
TOC
5.2.Non-normative References
[RFC2396]
Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, RFC2396, August1998 (TXT, HTML, XML).
TOC
Author's Address
ute Exchange, August2006 (TXT, HTML).
[RFC2119]
Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP14, RFC2119, March1997 (TXT, HTML, XML).
[RFC4646]
Phillips, A. and M. Davis, Tags for Identifying Languages, BCP47, RFC4646, September2006.
[W3C.REC-x
Dick Hardt
Sxip Identity
798 Beatty Street
Vancouver, BC V6B 2M1
CA
Email: [EMAIL PROTECTED]
URI:http://sxip.com/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
On 25-Nov-06, at 12:10 AM, Recordon, David wrote:
Decent number of changes to help clean-up the draft from what I posted
on the 19th. Getting close with only a few more things left on the
punch list!
Thanks for posting David. What do we have left on the list?
-- Dick
1 - 100 of 191 matches
Mail list logo
