Re: Backporting the 2.0 extension mechanism to 1.1

On 11/08/08 10:35 AM, Martin Atkins wrote: > In that referenced section it says: > > For the purposes of this document *and when constructing OpenID 1.1 > messages*, the extension namespace alias SHALL be "pape". > > (emphasis mine) > > I understand that to mean that when making a 1.1

Re: Backporting the 2.0 extension mechanism to 1.1

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:

Re: Problems with OpenID and TAG httpRange-14

On 20-Mar-08, at 4:40 AM, Noah Slater wrote: > On Wed, Mar 19, 2008 at 08:59:24PM -0700, Johnny Bufu wrote: >> Yes, it is. > [snip] >> The new claimed_id URL is the address of the discovered information >> (which is of interest to the RPs in this case). > > No, it r

Re: Problems with OpenID and TAG httpRange-14

On 19-Mar-08, at 6:42 PM, Manger, James H wrote: > [Aside: Browsers displaying the new URL in the address bar after a > 303 See Other is not a counter-example. Yes, it is. > The new URL is the address of the displayed response. The new claimed_id URL is the address of the discovered informatio

Re: Problems with OpenID and TAG httpRange-14

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

Re: Service Key Discovery 1.0

On 22-Jan-08, at 7:44 AM, Eran Hammer-Lahav wrote: > At some point, we have to draw a line between the "simple" and > "enhanced" solutions. There is baggage around XRI-related > technologies, but it doesn't make sense to keep inventing new > things just because people refuse to give it a ch

Re: SREG namespace URI rollback

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

Re: SREG namespace URI rollback

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 "

Re: Some PAPE Wording Clarifications

On 23-Oct-07, at 2:58 PM, David Recordon wrote: > Cool, committed. Great, thanks! > We ready to publish Draft 2? Yes; the only outstanding issue (from my point of view, which I suppose will have to wait for draft 3), is clarifying 'active authentication' means. Johnny __

Re: Some PAPE Wording Clarifications

+ [...] 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 implementati

Re: More questions about openid.ax.update_url

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

Re: More questions about openid.ax.update_url

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 author

Re: More questions about openid.ax.update_url

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 as

Re: More questions about openid.ax.update_url

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

Re: [OpenID] identify RP when it gets OpenID URL

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 pas

Re: PAPE Extension Specification

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 Attri

Re: PAPE Extension Specification

On 8-Oct-07, at 8:20 AM, David Recordon wrote: >>> # On the same topic, I have suggested before and there seemed to be >>> # agreement[1] that it's more useful if auth_age in the response is >>> # actually a timestamp (auth_time). >>> >>> Ah, good point. The spec didn't get changed; was there an

Re: PAPE Extension Specification

On 4-Oct-07, at 4:27 PM, Jonathan Daugherty wrote: > # +1 on clarifying what "active" means. Before getting to wording, I'm > # not totally sure what would be considered active authentication and > # what wouldn't. > > Agreed; that should be specified, too. If it can't be specified (I'm > inclin

Re: PAPE Extension Specification

On 4-Oct-07, at 2:45 PM, Jonathan Daugherty wrote: > - The description for max_auth_age mentions "active" vs. "indirect" > user authentication, but the spec defines neither. I had to read > 5.1 and 5.2 a few times to figure out precisely what they meant. > Since the distinction is i

Re: [OpenID] Announce: OpenID Authentication Draft 12 (finally)

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 pat

Re: [OpenID] Announce: OpenID Authentication Draft 12 (finally)

On 28-Aug-07, at 8:05 PM, Rowan Kerr wrote: > On 28-Aug-07, at 6:11 PM, Johnny Bufu wrote: >> On 27-Aug-07, at 7:05 PM, Peter Williams wrote: >>> A. fragment identifiers on user input are to be removed. Do not >>> remove >>> the separator. >> >> Go

Re: [OpenID] Announce: OpenID Authentication Draft 12 (finally)

On 27-Aug-07, at 7:05 PM, Peter Williams wrote: > Draft 12 - to be finalized post-hoc - says [Section 7.2] :- > > "If the URL contains a fragment part, it MUST be stripped off. See > Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information." > Ok. This is what I took away from a simp

Re: OpenID Provider Authentication Policy Extension

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 a

Re: OpenID Provider Authentication Policy Extension

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

Re: Using XRI Proxy Resolvers in OpenID discovery

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

Re: Differentiating between User Identifier and OP Identifier

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

Re: Differentiating between User Identifier and OP Identifier

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

Re: Using XRI Proxy Resolvers in OpenID discovery

On 30-Jul-07, at 12:08 PM, Eran Hammer-Lahav wrote: > But that doesn't address my point about XRI support. The referenced XRI Resolution document does. The goal of discovery is to provide the RP with an OpenID service endpoint that is authoritative for an identifier. To this end, the OpenID

Re: Using XRI Proxy Resolvers in OpenID discovery

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

Re: Differentiating between User Identifier and OP Identifier

Hi Eran, On 27-Jul-07, at 8:33 PM, Eran Hammer-Lahav wrote: > Section 2 describe the User-Supplied Identifier, and section 3 > bullet 2 > provided the workflow, allowing users to provide a User Identity or > an OP > Endpoint ID. Section 7.3.1 provides a little more information but > not much

Re: OpenID Provider Authentication Policy Extension

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.

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 y

Re: OpenID Attribute Exchange Protocol questions

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 up

Re: OpenID Attribute Exchange Protocol questions

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

Re: OpenID Attribute Exchange Protocol questions

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 t

Re: OpenID Attribute Exchange Protocol questions

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

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

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

Drummond, 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, John

Re: The CanonicalID Approach

On 8-Jun-07, at 3:04 PM, Drummond Reed wrote: > http://openid.aol.com/daveman692 - reassignable > http://openid.aol.com/daveman692#1234 - persistent > > If an XRDS for the reassignable identifier asserts the persistent > identifier > as a Canonical ID, a second round trip is not required becaus

Re: The CanonicalID Approach

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

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 th

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.

Re: Questions about IIW Identifier Recycling Table

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 1

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 respons

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

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 WordPre

Re: Auth 2.0 Extensions: Namespace Prefixes

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 valu

Re: Generalized solution to OpenID recycling (was RE: The "WordPress" User Problem)

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 appro

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

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.

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 solv

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 t

Re: Review of Yadis section in XRI Resolution 2.0 WD11

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 b

Re: Review of Yadis section in XRI Resolution 2.0 WD11

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 co

Re: attribute exchange value encoding

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 &

Re: Specifying identifier recycling

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 sche

Re: Specifying identifier recycling

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

Re: Specifying identifier recycling

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 disambigu

Re: Re-defining the Key-Value format

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 e

Re: attribute exchange value encoding

Hi Gouping, On 28-May-07, at 9:22 PM, Guoping Liu wrote: > I have a couple comments on Section 3.3.2 Default Encoding of a Binary > Value. > > First, the character set of standard Base64 encoding is not URL-safe. > Specifically, '+', '/' and '=' need to be URL-encoded. So, we need to > URL-encode

Re: Re-defining the Key-Value format (was: attribute exchange value encoding)

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

Re: attribute exchange value encoding

Hi Drummond, On 25-May-07, at 8:55 PM, Drummond Reed wrote: >> One remaining question is about the choice of encoding for strings. >> Percent-encoding (RFC3968) seems the simplest from a spec >> perspective, however some libraries provide (better) support for the >> older URL-encoding (RFC1738), w

Re: Realm spoofing spec patch

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 an

Re: Realm spoofing spec patch

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 resol

Re: attribute exchange value encoding

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

attribute exchange value encoding

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:

Re: clarifying section 11.2 in draft 11 for HTML discovery?

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 re

Re: directed identity + HTML discovery: is this right?

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 openid

Re: Final outstanding issues with the OpenID 2.0Authenticationspecification

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: > + > + As discussed in the +target="compat_mode">OpenID Authentication 1.1 > +

Re: encoding newlines in attribute values

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://ope

Re: encoding newlines in attribute values

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 _

Re: encoding newlines in attribute values

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 >

Re: encoding newlines in attribute values

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 newlin

encoding newlines in attribute values

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,

Re: Problem with check_authentication

On 13-Apr-07, at 8:53 AM, Kevin Richards wrote: > In the spec it shows an example of the 'signed' fields returned from a > check_id_* request as "mode,identity,return_to". However if you try > and do a I had a quick look at the spec and didn't this example. Can you please point to it? Curre

Attribute Exchange draft 5

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 u

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

On 10-Apr-07, at 12:01 AM, Rowan Kerr wrote: > While at Standard, I ended up hosting our own schema so we would have > a consistent set to work from and refer our partners to. It's based > on attributes from an older revision of AX but the metadata should be > pretty close to the existing format.

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 hav

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

On 7-Apr-07, at 3:56 AM, Martin Atkins wrote: > On the other hand, I also think it's a good idea not to modularize too > early: until there's some implementation experience, it's hard to say > with certainty what parts make sense as distinct modules. I'm not that > familiar with the AX stuff yet,

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

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

Re: Logout

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

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

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

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

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,

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 h

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 t

Re: Attribute Exchange pre-draft 5

I have uploaded changes proposed at the beginning of this thread into SVN; if you're up to reading the xml source, it can be viewed here: To summarize the open issues: a) ax.mode vs multiple URIs b) No useful gain

Re: Attribute Exchange pre-draft 5

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_

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 on

Re: SREG namespace URI rollback

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

Re: SREG namespace URI rollback

On 2-Apr-07, at 1:17 PM, Josh Hoyt wrote: > On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote: >> I think the missing namespace in SREG1.0 can cause problems; take >> this example: > > I was not proposing that we drop the namespace. Just that we don't > intro

Re: SREG namespace URI rollback

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 openid.ns.some_alias=http://openid.net/

Re: SREG namespace URI rollback

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 be

Re: Server-to-server channel

Chris, On 2-Apr-07, at 11:50 AM, Chris Drake wrote: > I've also noticed a lot of discussion about attributes, which begs the > question about how to handle things that change (eg: If I've given out > my email address to a dozen web sites, and then I change it, how does > my OpenID server propagat

Attribute Exchange pre-draft 5

Hello list! Since draft_4 [1] we've done some implementation and testing (as well as listened to community's suggestions on related issues), and have incorporated some changes into a pre-draft-5. Before publishing it I would like to see your comments about them or about other features / ch

Re: modulus and generator optional in association requests

On 20-Mar-07, at 1:36 PM, Granqvist, Hans wrote: > Once something complex is optional, typically few will > implement it, which means you can run into the inverse: > implementations that do supply optional values run into parties > that cannot treat those values correctly. > > This means that if

modulus and generator optional in association requests

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

Re: Is this a bug in the documentation?

John, > Section "4.4.1. Request Parameters" (for the "check_authentication" > mode) says that I should state a 'mode' in the parameters (and which > should equal 'check_authenticate'), but it also says: [...] In direct verification messages you should be sending openid.mode=openid.check_authent

Re: Thoughts on the Attribute Exchange proposal.

Hi Wayne! It's good to see someone interested in attribute exchange! On 9-Mar-07, at 11:25 AM, Wayne Pierce wrote: > 1. Updating information. When I update an attribute is there any > proposed way to notify subscribers without the subscribers having to > poll my URI? This is actually addresse

Re: OpenId & Yadis Question

On 25-Feb-07, at 3:35 PM, David Fuelling wrote: > 1.) User navigates to an RP, and enters a Claimed Identifier (e.g., > http://sappenin.gmail.com). > > 2.) A Yadis doc is returned as follows: > > > http://specs.openid.net/auth/2.0/server > https://sappenin.com/ > > > A.) Is this the proper way

attribute exchange draft 4 review

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." parameters. The O

Re: Proposal: An anti-phishing compromise

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

Re: Proposal: An anti-phishing compromise

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

  1   2   >