I was reviewing draft 10 to make sure our implementation complies
with all MUSTs, and I believe I've spotted an issue with the wording
in sections 5.1.2.1 and 5.1.2.2, specifically:
5.1.2.1. Successful Responses
A server receiving a properly formed request MUST send a response
with an
Johannes,
On 8-Dec-06, at 11:08 AM, Johannes Ernst wrote:
Dear Authentication 2.0 editors,
I know you are going to hate me (more changes!), but I hope the
attached comments are useful as you construct the final version of
the OpenID 2.0 Authentication document.
Not at all! As an
Hi Johannes,
Josh and I went through the remaining issues, so I have addressed and/
or commented on some of them below.
For easier tracking I've inserted [josh] after the ones that Josh
agreed to handle.
Thanks again for the feedback! The spec looks definitely better now
than a few days
On 12-Dec-06, at 11:31 AM, Joaquin Miller wrote:
When a message is sent as a POST, OpenID parameters MUST only be
sent in and processed from the POST body.
Does that mean the same as this:
When a message is sent as a POST, OpenID parameters MUST be sent
only in the POST body; the
On 12-Dec-06, at 9:10 AM, Johannes Ernst wrote:
11.2.2.2 Response Parameters
Not clear which values MUST be present and which not.
Also:
the language in this section is confusing. I don't quite
understand it. Not sure I can make a suggestion how to explain
it better, because so far I
On 28-Dec-06, at 3:47 PM, David Recordon wrote:
Sitting here in Seattle with Drummond and looking through the
spec. Section
7.3.3 says:
HTML-based discovery MUST be supported by Relying Parties. HTML-
based discovery is only usable for discovery of Claimed Identifiers.
OP
On 27-Dec-06, at 11:11 AM, Recordon, David wrote:
I think using cancel would add consistency between the modes, any
reason I'm not seeing why it is a bad choice?
Because then, only from the message contents, the RP wouldn't be able
to distinguish between responses to immediate and
On 3-Jan-07, at 8:55 PM, Recordon, David wrote:
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
Hi Rowan,
On 31-Jan-07, at 1:26 PM, Rowan Kerr wrote:
On 1/9/07, Johnny Bufu [EMAIL PROTECTED] wrote:
Please have a look at the latest (draft 4) OpenID Attribute Exchange
1.0 specification:
http://openid.net/specs/openid-attribute-exchange-1_0-04.html
This is looking good. I've been going
On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
but I'm still not sure how this helps with the phishing problem.
As you pointed out John, the issue is a rogue RP redirecting to a
rogue OP. So the rogue OP just steals the credentials and returns
whatever it wants.
In this case, the
On 2-Feb-07, at 12:25 PM, john kemp wrote:
If the authentication mechanism is phishable, a good OP is
supposed to
say phishable=yes. Otherwise it is cheating the user's trust.
Yes, RPs will just have to trust assertions from an OP. But with
all due
respect, I just don't see how the
On 2-Feb-07, at 1:53 PM, Josh Hoyt wrote:
Therefore, I think that the authentication mechanism is (or
at least can be) independent from whether the authentication channel
is phishable.
.. or, pushing it a bit further, I could ask/configure my OP to
always issue phishable=no for me, because
Hello list!
While reviewing our AX implementation, I came across a case where the
spec is not clear enough:
openid.ax.required
The value of this parameter is an attribute alias, or a list
of aliases corresponding to the URIs defined by
openid.ax.type.alias parameters.
Hello list!
The association request [1] seems to be insufficiently specified:
openid.dh_modulus and openid.dh_gen are not specifically marked as
optional, so according to the Protocol Messages [2] section they
should be mandatory.
However, while testing the openid4java code [3], it turns
Josh,
On 2-Apr-07, at 12:43 PM, Josh Hoyt wrote:
I'd like to change the simple registration specification so that it
uses the type URI that is currently in use in at least PIP and
MyOpenID as the namespace URI instead of defining a new value.
As far as I can tell, the only difference
Or even:
- RP doesn't support SREG1.0, but does support 2.0 extensions
- RP sees in an XRDS that the OP supports SREG1.* (if the same
namespace is used for both)
- the OP actually only supports SREG1.0
- RP sends a SREG1.1 request, but with
On 2-Apr-07, at 2:08 PM, Josh Hoyt wrote:
On 4/2/07, Johnny Bufu [EMAIL PROTECTED] wrote:
Sorry - I may be missing something, but I still say the problem
remains: if a SREG1.1 party builds a message with a namespace alias
different than sreg, it can confuse the other party which may
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
On 2-Apr-07, at 12:10 PM, Josh Hoyt wrote:
On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote:
- Added ax.mode parameters to all messages, to unambiguously identify
the message types; the values are:
fetch_request
fetch_response
store_request
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
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
On 6-Apr-07, at 10:34 AM, Johannes Ernst wrote:
Well, as one of the people that wrote the documents. We decided that
having separate documents was better. Thanks for sharing your
opinion. I have a different opinion.
For somebody who currently doesn't have an opinion on this subject,
could
On 5-Apr-07, at 9:24 AM, Recordon, David wrote:
I'm all about taking advantage of existing momentum, but I have a hard
time seeing anyone who cares about AX being unwilling to have this
discussion as a part of the ID Schemas community. If there is anyone,
I'd certainly like to understand the
On 6-Apr-07, at 4:09 PM, Laurie Rae wrote:
Seriously though, the issue here isn't really whether or not you
and your friends will go to the rugby game,
it's whether or not the rugby league organizers are trying to get
you to go to the rugby game at the appropriate venue.
I would say the
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
Thanks everyone for the good feedback and discussions during the last
week. I went through the messages and added clarifications and
modifications for the issues where there seemed to be consensus.
Since there were a handful of changes, I've tagged the result and
asked David to put draft 5
The core spec doesn't allow newline characters (\n) in any openid.*
values. Currently, Attribute Exchange doesn't specify a way to encode
newlines in attribute values.
At a minimum, we could specify a way to escape just the \n character.
Other option would be to do something more generic,
On Apr 19, 2007, at 10:46 AM, Josh Hoyt wrote:
Each attribute already has to define its encoding rules and data-
type. The mechanism for encoding a newline can be part of this
encoding, if newlines are allowed in the value. Once there is one
attribute that has a defined encoding for newline,
On 20-Apr-07, at 11:18 AM, Dick Hardt wrote:
To expand on that and include Mark Wahl's proposal about locale
encoding[1] in a standard way for attributes so that the libraries
can do the right thing 99% of the time.
I would propose that AX data have a default encoding that can be
Hans,
On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote:
Just so we're all on the same page: Can you post a link
to the referenced proposal?
Mark has announced it here on the list:
http://openid.net/pipermail/specs/2007-April/001630.html
Johnny
On 27-Apr-07, at 3:46 PM, Johnny Bufu wrote:
The default encoding would then be applied only when a attribute-
specific encoding was not used.
With help from Mark Wahl I've put this into the spec and wrapped up
the remaining issues.
The latest version is in SVN here:
http://openid.net/svn
David,
On 18-May-07, at 11:09 AM, Recordon, David wrote:
Hey Marius,
Good point, committed a patch so please review! :)
On 18-May-07, at 11:08 AM, [EMAIL PROTECTED] wrote:
+ t
+ As discussed in the xref
+target=compat_modeOpenID Authentication 1.1
+
On 18-May-07, at 2:19 PM, Peter Watkins wrote:
[...]
Would we put the OP-Local Identifier in both openid.claimed_id *and*
openid.identity?
The user/OP can choose to send the local_id as the claimed
identifier, or any other claimed identifier that delegates to the
local_id sent as
On 24-May-07, at 8:19 AM, Peter Watkins wrote:
Section 11.2 states
If the Claimed Identifier was not present in the request
(openid.identity was http://specs.openid.net/auth/2.0/
identifier_select), the Relying Party MUST perform discovery on
the Claimed Identifier in the response to
Hello list,
While at IIW, I asked around what people thought about the encoding
mechanisms we've added recently, in order to allow for transferring
any data types. The consensus was that everyone would prefer
something simpler and lighter.
So I've rewritten the encoding section, such that:
On 24-May-07, at 5:15 PM, Johnny Bufu wrote:
Please review section 3.3 Attribute Values to see if there are any
issues.
Of course it helps if there's a link to click on... I missed it in
the previous message:
http://openid.net/svn/filedetails.php?repname=specificationspath
Josh,
On 24-May-07, at 4:19 PM, Josh Hoyt wrote:
Please review the additions. If you'd like to see the
specific changes, you can look at the diffs in revision control[3].
Looks good to me. One minor issue about the wording - we have now two
return URL verifications: one done by the OP and a
On 24-May-07, at 5:54 PM, Recordon, David wrote:
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
Hi Claus,
On 28-May-07, at 5:55 AM, Claus Färber wrote:
Johnny Bufu schrieb:
So I've rewritten the encoding section, such that:
- for strings, only the newline (and percent) characters are required
to be escaped,
(to comply with OpenID's data formats), using percent-encoding
Hi Claus,
On 28-May-07, at 3:58 PM, Claus Färber wrote:
Johnny Bufu schrieb:
Encoded for AX using Key-Value Form Encoding (OID 2, 4.1.1.)
openid.ax.foo.uri:http://example.com/foo/100%2525pure
AX has nothing to do directly with key-value encoding. I see no
reference to percent-encoding
On 30-May-07, at 6:21 PM, Martin Atkins wrote:
John Panzer wrote:
Has there been a discussion about an extension to map to/from i-
numbers
via AX? If there were a generic attribute you could stuff an i-
number
or a hash of an internal ID in there to help solve the disambiguation
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
How should the discovery process work?
How should fragments work with delegation (both as the claimed
identifier and the provider-local identifier)?
Here's how I see the fragments approach working:
a) Discovery: strip the fragment from the
Josh,
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
Providers can also provide a redirect from the general form of the
identifier to the current version of the identifier so that users do
not need to remember or type the uniquified version. This is pretty
much equivalent to the fragment scheme,
On 29-May-07, at 2:33 AM, Claus Färber wrote:
Johnny Bufu schrieb:
The attribute metadata can be used to define attribute-specific
encodings, which should deal with issues like this.
Ah, so the _usual_ way is that the metadata (Can this be renamed to
datatype definition? metadata is very
Hi Drummond,
On 30-May-07, at 10:45 PM, Drummond Reed wrote:
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
On 31-May-07, at 5:34 PM, Recordon, David wrote:
I'd recommend adding a section which pulls together the HEAD and GET
methods and describes how'd they be used in conjunction.
In the interest of keeping it light and simple to process, I believe
it would be enough to make this explicit just
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
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
On 5-Jun-07, at 8:00 AM, Recordon, David wrote:
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.
Hi Drummond,
On 5-Jun-07, at 9:44 AM, =drummond.reed wrote:
I see no reason we can't add the rules for
reassignable-URL-to-persistent-URL mapping as well, since it's
simply a
matter of the RP confirming that the persistent identifier is also
authoritative for the XRDS.
If we approached
On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.
Martin's proposal seems like a minor improvement to me - iterating
thorough openid.ns.* or splitting the value
On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote:
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote:
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
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
Hi David,
The idea was to list as columns the things potentially affected by
this change and important enough that we cared. In the end we chose
'URL + public fragment' as the one with the most check marks.
See below my comments; maybe others can correct / fill in the gaps.
On 5-Jun-07, at
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
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
On 8-Jun-07, at 2:26 PM, Drummond Reed wrote:
See my next message about this. It works identically to David's
examples
(just substitute these as reassignable and persistent identifiers)
except it
has the advantage that it does not require an extra round-trip for
discovery/verification
Hi James!
On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
1. I noticed a few typos in the examples. In section 5.1, it gives an
example of a fetch_request request reading:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ns.ax=fetch_request
...
This would be a copy / paste
On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
My question about the transaction ID in the update URL still stands:
won't a positive assertion response include openid.identifier and
openid.claimed_id, which should be enough for the RP to match up the
response? Or do you expect the OP to
On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
Not entirely; the OP MUST NOT honor check_authentication requests for
shared associations (this would allow a type of attack).
Okay. In that case it sounds like it would be best practice to
generate a private association handle for each
On 10-Jul-07, at 8:43 AM, James Henstridge wrote:
On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
Given that there doesn't seem to be any way to recover from this
situation, it seems like private associations are the only sane
option
for unsolicited responses.
An update message
On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
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
2) I'm fine with time coming back instead of number of seconds.
3) Changed to integer.
Great,
On 28-Jul-07, at 6:14 PM, Eran Hammer-Lahav wrote:
The spec requires HTML discovery but not the other
two, but users are expected to try their XRI identities not knowing
what the
RP will support.
This is not correct. For URL identifiers Yadis and HTML discovery are
both required for
On 28-Jul-07, at 10:00 AM, Eran Hammer-Lahav wrote:
Section 7.3.1:
If more than one set of the following information has been
discovered, the
precedence rules defined in [XRI_Resolution_2.0] are to be applied.
This somewhat confusing when combined with section 7.3.2.2:
Once the
On 30-Jul-07, at 8:48 PM, Eran Hammer-Lahav wrote:
In this case, it sounds like an XRDS document MUST no include both
an OP Endpoint element and a Claimed Identifier element.
I don't see this implied anywhere. Do you have a specific pointer or
a clear reasoning for this?
If an XRDS has
On 30-Jul-07, at 12:58 PM, Eran Hammer-Lahav wrote:
It has been mentioned on this list that XRI might be optional in
OpenID 2.0.
If you read the spec with that mindset you can find ways to prove it.
Yes, support for XRIs is left for each RP to decide (as is a number
of other things).
David,
On 9-Aug-07, at 11:28 AM, Johnny Bufu wrote:
On 21-Jul-07, at 4:55 PM, Recordon, David wrote:
5.2
2) I'm fine with time coming back instead of number of seconds.
I wanted to bring openid4java up to the latest PAPE spec, and it
seems the above was not checked in yet. Do you still
On 29-Aug-07, at 12:19 AM, Peter Williams wrote:
Why do I care so much about a #?
Discovery in draft#12 a required security procedure - used when
verifying the validity of an Auth Response.
I agree: everything starts and then relies on discovery; if it's
broken nothing works. It's patched
On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote:
# Yep, the idea is for the PAPE spec to define a few generic and
# agreed upon policies and then RPs and OPs can create others. Thus
# if there isn't agreement on a policy, there would be multiple policy
# URIs. Same concept as in
On 16-Oct-07, at 7:58 PM, Manger, James H wrote:
Use case: Alice wants to use different OPs for different RPs, while
keeping the same URL (eg http://alice.example.net/). For instance,
when logging into a service hosting her backups she wants to use an
OP that requires a one-time
Hi James,
On 17-Oct-07, at 2:42 AM, James Henstridge wrote:
I have a few more questions about the update_url feature of OpenID
attribute exchange that I feel could do with answers in the
specification.
For the questions, imagine an OpenID RP with the following properties:
1. The RP
On 17-Oct-07, at 2:42 AM, James Henstridge wrote:
The next question is how much information from the original OpenID
authentication request/response can the RP expect to be included in
the subsequent update responses.
Attribute Exchange is an OpenID extension, so a full/valid/positive
On 17-Oct-07, at 2:42 AM, James Henstridge wrote:
The next one is not so much a question as an observation: As an
identity URL may change its delegation over time (possibly without the
underlying OP's knowledge), it is possible that an RP will receive
updates from an OP that is not
On 22-Oct-07, at 3:23 AM, James Henstridge wrote:
If the RP does not store any user attributes (and requests them with
each transaction from the OP), why does it want to be updated when
the user changes an attribute value at their OP?
What I meant was that the RP would act as a cache for the
+ [...] For example it is recommended that if the OP
+specified the Multi-Factor Physical Authentication policy
and the RP
+requested the Multi-Factor Authentication policy, that the RP's
+requirements were met.
This puts undue requirements on the RP
David, Josh,
Reviving an old thread here...
On 2-Apr-07, at 5:06 PM, Johnny Bufu wrote:
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
On 1-Nov-07, at 12:06 PM, David Recordon wrote:
Sorry it took me a few days, but seems alright to me. I think a
larger question would be if there should be any material
differences with SREG 1.1 such as adding a few additional common
fields.
I believe Josh's argument back in April was
On 19-Mar-08, at 2:51 AM, Noah Slater wrote:
On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
A request for an OpenID Identifier SHALL NOT issue a 303 response.
This is even worse and also backwards incompatible. All the OpenIDs
that
currently use 303 redirects, including
On 11/08/08 12:49 AM, Martin Atkins wrote:
I notice that, like sreg, the pape extension is supporting 1.1 by simply
hard-coding the pape prefix on its arguments.
Where/how? To my knowledge the opposite is true, per the last paragraph
here:
79 matches
Mail list logo
