Re: Requiring Pseudonymous Identifier

Chris Messina wrote: So, imagine I use directed identity in a school application... when I sign in to the OP, it will return something like schoolname.edu/student as the identifier. Overloading our existing concept of an identifier to support identifying a group worries me. Most consumers ex

Re: Defining how OpenID should behave with fragments in the return_to url

James Henstridge wrote: On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard wrote: One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that so

Re: Defining how OpenID should behave with fragments in the return_to url

This looks similar in principle to the "AJAX"-ish (though not really AJAX at all) mode of OpenID that was in the early demos but no-one actually seems to have implemented in practice. The trick there was to do the OP dance in a hidden iframe and have the return_to page communicate with the ou

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

Dick Hardt wrote: I'd prefer to narrow the scope of the WG and keep it focussed on a small number of goals. A separate WG on SREG would be preferred, but I think it is a disservice to the community to have two specs having such significant overlap. Choice in this case leads to confusion and re

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

Henrik Biering wrote: Agree! If the range of SReg attributes is expanded, however, I would suggest to add phone number (incl. quality as suggested for email) and possibly street+city address line(s). That would make it possible to fill in a somewhat larger part of typical registration forms.

OpenID Authentication 2.0 Errata

Hi folks, It seems that we don't currently have any central place to document the issues with OpenID Authentication 2.0, so I started a wiki page for it: http://wiki.openid.net/OpenID-Authentication-2_0-Errata Currently it only has one issue, which is the one that I encountered today that i

Re: Request for consideration of Working Group Charter Proposal

Allen Tom wrote: > Hi Nat - I'm not quite sure what you mean by "class". > Nat previously talked about the idea of bundling several attributes together into a single namespace rather than assigning a URL to each individual scalar attributes. He referred to it as a "class" though you might inst

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Allen Tom wrote: > Hi Martin, > > The intent is to be able to identify applications which were not > deliberately designed to be malicious. Well designed malicious apps > would piggy back off of another app's CK or just cycle through a list of > CKs to evade detection. > > However, there have

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Allen Tom wrote: > > For the time being, we prefer to require CKs for client applications > (even if they can't be verified) mostly to make it easy for us to pull > the plug on specific applications if they are discovered to be severely > buggy or dangerous. We'd also like to require pre-regist

Re: Completing the SREG 1.1 specification

I agree that it's not ideal to have both, and in an ideal world everyone would use AX, but currently SREG seems to be more widely deployed than AX. This working group proposal was motivated not by some desire to needlessly perpetuate SREG but rather by actual real-world interop problems I've h

Completing the SREG 1.1 specification

consistent with the purpose and scope. Proposers: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL PROTECTED]) * ... Initial Editors: * Martin Atkins, Six Apart ([EMAIL PROTECTED]) * David Recordon, Six Apart ([EMAIL PROTECTED]) [1]http://openid.net/spec

Re: OpenID/OAuth hybrid - without app pre-registration

Breno de Medeiros wrote: > > The consumer key is an independent issue of pre-registration. Say a > site hosts multiple apps. The realm indicates the site, the consumer > key indicates the app. The presence of the consumer key (even in a > scenario without pre-registration requirements) is useful t

Re: OpenID/OAuth hybrid - discovery

Dirk Balfanz wrote: > > We're defining an OpenID extension. Consumer will want to know whether > or not a given endpoint speaks that extension. That's all it's doing - > just like AX or PAPE have a section on discoverability. It also gives > consumers a way to look for the combined OpenID/OAuth

Re: OpenID/OAuth hybrid - discovery

Dirk Balfanz wrote: > I'm not sure I understand what the commotion is about :-) > > OAuth discovery (when it is done), will answer the question: given the > URL of a resource, where do I go to get access tokens for that resource. > The question answered by the XRD element described in Section 5

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

rtin, > > Not sure why you say that requiring pre-registration and having an open > stack are mutually exclusive. Are you saying that there's no benefit for > service providers to provide a standard interface to developers? > > Allen > > > Martin Atkins wr

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Breno de Medeiros wrote: > > At this point, there is no reasonably secure formulation of OAuth > without key registration. > > We hope to add one for the hybrid protocol. > If that is true then OAuth is broken. Wouldn't it be better to fix this problem in OAuth itself rather than only in the h

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Allen Tom wrote: > Manger, James H wrote: >> Ideally, an app would attempt to access a protected resource at an SP and >> get: >> * A 401 Unauthenticated response from the SP; with >> * A “WWW-Authenticate: OAuth” header; with >> * A parameter providing the authorization URL; and >> * Another para

Re: Proposing an OpenID Authentication 2.1 Working Group

Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Deleg

Re: Proposing an OpenID Authentication 2.1 Working Group

I'm in favor of working on a new version of OpenID Authentication with new features, but I think it's also important not to forget about 2.0. I think we should also publish a minor revision to 2.0 which includes only the errata and clarifications, not the new features. I'd like to have a spec

Re: [OpenID] OpenID Extension to handle Emails Addresses?

Hallam-Baker, Phillip wrote: > > Well we already have a specification for that, it is the core > architecture of the Internet: DNS. We use the DNS SRV record for service > discovery. It is what it is designed for. It provides for fault > tolerance, load balancing, fall over just like an email M

Re: [OpenID] OpenID Extension to handle Emails Addresses?

David Fuelling wrote: > >1. The arguments about using DNS could apply to OpenID in general. > However, OpenID doesn't do anything with DNS. Why is this? What > were the compelling reasons to not use DNS with OpenID? Is there > an FAQ page somewhere about that? I have onl

Re: [OpenID] OpenID Extension to handle Emails Addresses?

David Fuelling wrote: > > I would even entertain the notion of the OpenID extension doing DNS > lookup first, then EAUT, though I need to think more on the topic. > Alternatively, maybe we make DNS optional. > At this point I'll throw in my more recent post about why DNS must be supported an

Re: "This is user's URI" for Assertion Quality Extension

SitG Admin wrote: >> What's the use-case? > > If the RP doesn't care about distinguishing between users that have > accounts at a site but identify themselves as such anonymously, it can > reclassify them as "users that have accounts at a site", consolidating > what could be a large number of i

Re: "This is user's URI" for Assertion Quality Extension

SitG Admin wrote: > http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html > > I'd like to see the 4th draft of this include a "URI level" > authentication property. > > I'd like to know whether the OP is as

Re: Backporting the 2.0 extension mechanism to 1.1

Nat Sakimura wrote: > Actially, that interpretation is not right. In draft 3, we have made it > clear. > Draft 3 now seems to say: For the purposes of this document and when constructing OpenID 1.1 and 2.0 messages, the extension namespace alias SHALL be "pape". Which now seems to re

Re: Backporting the 2.0 extension mechanism to 1.1

Johnny Bufu wrote: > > > 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 t

Backporting the 2.0 extension mechanism to 1.1

I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the "pape" prefix on its arguments. This approach is troublesome for the Net::OpenID::Consumer perl library because it deals only in extension URIs, and supports sreg in 1.1 as a special case. In order to pres

Re: OpenID 2.0 Specifications

Arshad Khan wrote: > Hi Martin, > > Thanks for this. > > Is it possible to get the specification in word or pdf format? I don't think this is published online, but you should be able to load the HTML version into Word and save it as .doc if necessary. > Also, I am not clear if I need to read a

Re: OpenID 2.0 Specifications

Arshad Khan wrote: > Hello, > > Can I please have OpenID 2.0 specifications? > > Can I also request link to software codes for sever and consumer? > http://openid.net/specs/openid-authentication-2_0.html http://openidenabled.com/ http://code.google.com/p/dotnetopenid/ http://code.google.com/p/o

Re: Responding to a 2.0 request with a 1.1 response

(sorry for responding to myself.) Martin Atkins wrote: > > Another similar and perhaps more likely case is when a user does > 2.0-style delegation to a clavid.com identifier, omitting the 1.1-style > delegation. Net::OpenID::Consumer with 1.1 compatibility enabled fails > in th

Responding to a 2.0 request with a 1.1 response

A few weeks back I got a report that the in-progress 2.0 branch of the perl libraries (Net::OpenID) wouldn't authenticate against the provider clavid.com, because while they accept 2.0 requests they respond with 1.1-format assertion messages. Net::OpenID did have a bug in that it wasn't allowi

Re: Origin of DH modulus

Dwayne C. Litzenberger wrote: > http://openid.net/specs/openid-authentication-2_0.html#pvalue states: > > Appendix B. Diffie-Hellman Key Exchange Default Value > > This is a confirmed-prime number, used as the default modulus for > Diffie-Hellman Key Exchange. In hexadecimal: > >

Re: Notice of vote on the proposal to create the PAPE working group

Mike Jones wrote: > In accordance with the OpenID Foundation IPR policies and procedures > , this message > notifies OpenID Foundation members that a vote that will be held on the > creation of the PAPE working group between noon Friday, June

Auth 2.0 spec errata regarding delegation vs. directed identity

In a conversation yesterday I found out that a particular existing OpenID Provider[1] is acting in a way that defeats delegation. This is allowed by the spec, but has non-obvious degenerate behavior: * You delegate to your identifier with this provider * Another user of this provider logs i

Re: Using email address as OpenID identifier

Paul E. Jones wrote: > > > I’ll give you that one: that’s certainly easier. But, does not cause > some confusion? After all, one’s identity is not yahoo.com, but that is > the identity provider. Perhaps the prompts around the Internet ought to > Say “OpenID Provider:” instead? :-) > I pr

Re: Using email address as OpenID identifier

Paul E. Jones wrote: > > Perhaps it is important to say, though, that I do not think it requires > the e-mail providers to get on board with this (in my view) simpler > notation. I could use an ID like [EMAIL PROTECTED] and that should > work, if myopenid.com would publish the appropriate NAPT

Re: Integration with Enterprise Directory Services

Drummond Reed wrote: > Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs > in an LDAP directory for that very reason -- to establish standard OIDs for > this attribute. LDAP already has a URI attribute type, but downcasting an > XRI into a URI just to squeeze it into that

Re: handling of url redirection

Jonathan Daugherty wrote: >> This is what I was getting at- it'd be good to give users an identical >> experience when they sign into various OpenID-enabled apps. > > Just to be clear, this is not an interop issue. This is a matter of > drawing the line between what is sane and what is not. Fo

Re: SREG 1.1 Request parameters

Enis Soztutar wrote: > > As far as I understand, the distinction between sreg.required and > sreg.optional is entirely in the responsibility of the consumer and > there is not reason for the protocol to include this arbitrary division. > An OP implementation will just merge the two fields and t

Re: OpenID 3.0

I apologise that this message doesn't directly address any of the points you've made, but others have been doing that. I just want to make a general point: In my opinion, we should resist the urge to start specing "OpenID 3.0" (aka OpenID vNext) and try to do everything else that needs to be do

Re: OpenID Inline Authentication Extension 1.0 Draft 1

John Ehn wrote: > Martin, > > Thanks for the response! I'm looking at those specs now, and I really > like the flow of the HTTP Authentication spec, because it looks like > it's solving the problem of passing the OpenID Identifier to the RP in > an automated way, which is really cool. Looks li

Re: OpenID Inline Authentication Extension 1.0 Draft 1

John Ehn wrote: > The Inline Authentication Extension attempts to solve the problem of > legacy and interactive applications (Telnet/SSH) that are unable to > launch a client Web Browser to perform an authentication request. > > http://extremeswank.com/openid_inline_auth.html > > This is done thr

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

Josh Hoyt wrote: > On 6/11/07, Martin Atkins <[EMAIL PROTECTED]> wrote: >> Presumably the recommendation would be to have several identifiers >> attached to a single account just as is recommended today. I would point >> most of my identifiers at one canonical identifie

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

Josh Hoyt wrote: > On 6/8/07, David Fuelling <[EMAIL PROTECTED]> wrote: >> If in 50 years, a given canonical URL domain goes away, then couldn't a >> given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? > > If I understand the way that David Recordon and Drummond are proposin

Re: The CanonicalID Approach

Josh Hoyt wrote: > On 6/9/07, Martin Atkins <[EMAIL PROTECTED]> wrote: >> I'm assuming that the RP authenticates >> http://inconvenient.example.com/001, not >> http://impersonation.example.com/mart. Just as with delegation, if I can >> successfully authent

Re: The CanonicalID Approach

Josh Hoyt wrote: > On 6/8/07, Martin Atkins <[EMAIL PROTECTED]> wrote: >> I figure that you could potentially use the same mechanism as delegation >> to avoid the extra discovery iteration. >> >> The problem, as with delegation, is that you need to duplicate

Re: The CanonicalID Approach

Josh Hoyt wrote: > On 6/7/07, Recordon, David <[EMAIL PROTECTED]> wrote: >> What I'd like to markup is that my three reassignable identifiers so >> that they all use my LiveJournal userid URL as the persistent >> identifier. It should be noted that also marking them as synonyms to >> each other fo

Re: Auth 2.0 Extensions: Namespace Prefixes

Johnny Bufu wrote: > 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 open

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

=drummond.reed wrote: > > As Martin has pointed out, the purpose of the CanonicalID element in XRDS is > to support reassignable-to-persistent identifier mapping. Although this is a > native function of XRI resolution (because XRI architecture was explicitly > designed to address the reassignable-

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

Claus Färber wrote: > Marius Scurtescu schrieb: >> The new attribute values are needed in order to signal an OpenID 2 >> provider. > > Why is this necessary? Is OpenID 2 incompatible? In other words, what > happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x > Provider? > > If

Re: Specifying identifier recycling

Johnny Bufu wrote: > > We did look at this (with Drummond) in December. The bottom line is > that it can't be done easily - a mechanism similar to XRI's canonical > ID verification would have to be employed, to confirm that the i- > number actually 'belongs' to the URL on which discovery was

Re: Specifying identifier recycling

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 > problem. Alternatively it'd be nice to have a way to

Auth 2.0 Extensions: Namespace Prefixes

As currently defined, an extension has a global namespace URI as well as a request-local alias/prefix. For an extension with the namespace http://example.com/blah that has a field "foo", the following fields are to be sent: openid.ns.blah=http://example.com/blah openid.blah.foo=bar

Re: Authentication Protocols for Non-browser Apps

Gabe Wachob wrote: > Hi Mart- > I'm trying to figure out if what you are proposing covers the same > use case that I discussed at > http://openid.net/pipermail/general/2007-March/002005.html > I'm not clear actually what you are trying to do with HTTP > Authentication, and it may be com

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

James Walker wrote: > > As an implementor - there would be extremely positive benefits from > having a base set of attributes defined and available @ > schema.openid.net . I agree that the people most interested right now > are the OpenID community & implementors and it makes sense (to me) for > o

Authentication Protocols for Non-browser Apps

Today I've re-written the HTTP Authentication bindings I previously specified to support the use of associations rather than using dumb mode exclusively. The new specification more closely mirrors the browser-based OpenID Authentication protocol and wherever possible just adapts it to go over

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

Johnny Bufu wrote: > > These two seem to have been the rationale of the recent discussions > about splitting the OpenID spec into core/discovery/etc., which > seemed to make sense to a number of people (I'm just not sure if it's > worth / good tactical move at this stage). > I tend to

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

Johnny Bufu wrote: > > I believe a key difference here is between what people would be > willing to do, and what people actually (will) do. For example: > > - I would be willing to go to a rugby game, but I don't know if any > of my friends are going, so I probably won't go > - most of my fri

Re: password-free login without SSL and OP reliance (an anti-phishing solution)

Douglas Otis wrote: > > For clarity, OpenID Authentication 2.0 - Draft 11 "4.1.1. Key-Value > Form Encoding" should change to something like "Keyword-Value Form > Encoding". Avoid using the word "key" to mean field or label. This > will cause confusion. > While I believe that "key-value

Re: Web Access Management

McGovern, James F (HTSC, IT) wrote: > Are you saying that the large vendors aren't participating because OpenID > forces too many things to be open? > No, I'm saying that large vendors aren't participating because it's not clear exactly what the expectations are for openness. _

Re: Web Access Management

Hans Granqvist wrote: >> Ping demoed OpenID technology at RSA. >> >> I hear Novell and IBM are looking at supporting OpenID. >> >> Microsoft has said they will in future products. >> >> Oracle and CA are following OpenID. >> >> So, yes. :-) >> > > I'm curious why almost all of these companies are

Re: Server-to-server channel

Chris Drake wrote: > Hi Martin, > > Yes - sorry - I accidentally hit "reply" instead of "reply all". I > later did re-post to the list though. For the benefit of the list, > your reply is at the end here. > > Re-reading my reply, I think my wording sounded pretty strong, and I > might not have m

Re: Server-to-server channel

[I initially sent this to Chris directly, because he sent his message to me directly. Then I noticed he'd also replied on the list. Hopefully he'll see this before my private reply and we can avoid another go-around of duplicate messages!] Chris Drake wrote: > > MA> For some things it's legit

Re: Server-to-server channel

Chris Drake wrote: > Hi Martin, > > You wrote > MA> The "age" of the information needs to be taken into account here. > > When the information (rightly) lives at the OP instead of the RP, none > of that age complexity exists. > > It's *my* name. It's *my* credit card. If any RP wants this info,

Re: Server-to-server channel

Anders Feder wrote: > > Imagine an RP requesting your bank account number X from your OP. Time > goes by, and your OP goes out of business. Later, you switch banks and > your account number X is assigned to someone else. In the meantime, the > RP has been preparing a payment for a job you have

Re: SREG namespace URI rollback

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

Re: Promoting OpenID

McGovern, James F (HTSC, IT) wrote: > > Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces > such that user-centric identity is built into their product? > Mm tasty acronym soup! ___ specs mailing list specs@openid.ne

HTTP Authentication Bindings for "two-party" OpenID Authentication

OpenID is currently only useful for three-party authentication where an end user (usually a human) is logging in to an RP with the help of an OpenID provider. However, we do not have a solution for a software agent representing itself. Software agents don't need an OpenID Provider in the same

Re: Extensions key prefix

Rowan Kerr wrote: [snip] > i.e. While the spec for Attribute Exchange uses "openid.ax" for its > message keys, and Simple Reg 1.1 uses "openid.sreg", in reality the > keys received in a message are determined by whatever comes after the > key openid.ns.* where the value is the URI of the exte

Re: XRD-based Service Discovery - Draft 1

Martin Atkins wrote: > > In respose to the discussion recently about modularizing the discovery > part of OpenID Authentication 2.0, I've put together a possible first > draft of a specification for doing service discovery using XRDS. [snip] > > > (I was going to p

XRD-based Service Discovery - Draft 1

In respose to the discussion recently about modularizing the discovery part of OpenID Authentication 2.0, I've put together a possible first draft of a specification for doing service discovery using XRDS. This document is really just the XRDS-related parts of Yadis but refactored slightly.

Re: HTTPS status

Alaric Dailey wrote: > Eddy Nigg and I brought up the issue of requiring SSL a while back, since > then I have been swamped, it looked like there was some more talk about it > since then. > > I know that there are several other people, that are concerned about this > too, and it has even been

Re: Proposal for Modularizing Auth 2.0 Discovery

Gabe Wachob wrote: > > Basically, the Discovery Spec would specify that for any identifier scheme > to work with OpenID, it MUST define a way of being constructed into an HTTP > URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there > are other ways of resolving it, then impleme

Re: Modularizing Auth 2.0 Discovery

Having reflected on people's comments a bit, I have a slightly adjusted set of proposals. 1. Take the bits about parsing XRD service elements from the Yadis spec and call it "XRD service discovery for URIs". 2. Have "XRD service discovery" delegate the actual mapping of a URI onto an XRD

Re: Modularizing Auth 2.0 Discovery

Recordon, David wrote: > Yeah, I'd see this either as a Yadis 1.1 (using things like LocalID > versus OpenID:Delegate) or have the OpenID URL Discovery spec replace > Yadis, referencing chapter 3 as needed. > > I think I'd lean toward swallowing Yadis in as a part of this spec so it > is one fewer

Re: Modularizing Auth 2.0 Discovery

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

Re: Modularizing Auth 2.0 Discovery

Drummond Reed wrote: > > Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, > email addresses, phone numbers, etc.) would be handled by OpenID Discovery. > I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ri

Re: Modularizing Auth 2.0 Discovery

Recordon, David wrote: > Well there already is the Yadis spec. Maybe the Yadis spec remains > separate versus becoming part of the OASIS XRI Resolution document? > The XRDS-related parts of the Yadis specification seem to duplicate requirements from XRI Resolution chapter 3. In the interests o

Re: Modularizing Auth 2.0 Discovery

Drummond Reed wrote: > I've always been supportive of breaking out OpenID Discovery into a separate > spec. I wouldn't break it out into separate specs, however, because > discovery for any OpenID identifier has have much more in common than they > have different. For example, they all need to expl

Re: Modularizing Auth 2.0 Discovery

rob wrote: > Martin Atkins wrote: >> My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It >> would just state that an identifier is "a URI". Later in the spec, where >> currently it enumerates a bunch of ways to do discovery, it'd just say

Re: Modularizing Auth 2.0 Discovery

Dmitry Shechtman wrote: > >> Then we'd publish in parallel the following two ancillary specifications: >> * OpenID Discovery for HTTP and HTTPS URIs >> * OpenID Discovery for XRI URIs. > > The latter being "prepend http://xri.net/ to the XRI and use OpenID > Discovery for HTTP". > I thi

Modularizing Auth 2.0 Discovery

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

Re: [OpenID] OpenId & Yadis Question

David Fuelling wrote: > I'm wondering if the following is a correct interpretation of how OpenId 2.0 > uses Yadis. Any clarifications are appreciated. > > 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:

Re: [OpenID] Wiki page: Attempting to document the "Email Address as OpenId"debate.

Hallam-Baker, Phillip wrote: > > Over time everyone will own their own DNS domain > and it will form the hub of their personal > communications system. All communication modes > will map onto the single unified communication identifier. > I don't necessarily disagree with many of your argumen

Re: Yadis/XRDS Service Element URI Question

David Fuelling wrote: > > Does Yadis/XRDS require the presence of a URI child in a service element? > Is it legal to define new children elements? Is that advisable? > I believe that it is permissable to add new child elements in your own XML namespace. ___

Re: Proposal: An anti-phishing compromise

Recordon, David wrote: > I agree that things like age should be in an extension, though I think > this single piece of data is useful in the core protocol. I'm sure the > exact definition of phishing resistant will come back to bite us in > sometime in the future, but lets deal with it then instea

OA2.0d11: Minor nit-pick regarding normalization

Hi, This is a really minor thing I just spotted due to leaving my browser open on the relevant part of the spec and coming back to it later. :) The normalization table in appendix A.1 lists several examples of the normalization of URIs. The last few examples are as follows: http://exampl

Re: DRAFT 11 -> FINAL?

Rowan Kerr wrote: > > Also, the spec mentions AJAX interactions, but I don't see how you can > actually use AJAX with OpenID, since none of the responses are in XML > format .. it relies entirely on GET or POST redirection, not to > mention that you have to make cross-domain requests which > XmlHt

Re: HTML parsing in HTML-based discovery

Claus Färber wrote: > > In order to facilitate regexp parsing, just requiring the start and end > tags is not enough. Additional restrictions may also be necessary to > avoid cases where too simple regexp-based parsers might fail: > > - start with attributes. > - order of attributes within the

Re: DRAFT 11 -> FINAL?

Since your list is long, I'm only going to address things I have an answer to. I'll leave the rest to other people. :) Claus Färber wrote: > - > | 4.1.1. Key-Value Form Encoding > | > | A message in Key-Value form is a sequence of lines. Each line begins > | with a key, followed by a colon,

Re: OpenID.net Service Type Namespaces

Recordon, David wrote: > > http://specs.openid.net/authentication/2.0/signon > http://specs.openid.net/authentication/2.0/server > http://specs.openid.net/authentication/2.0/identifier_select These seem just fine to me. (+1, I guess!) > So very verbose and organized. There is no need for an xml

Re: OpenID Exchange

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

Re: Consistency of negative responses to checkid_immediate requests

Josh Hoyt wrote: > > It's confusing to me make the failure response to an immediate mode > request be "id_res", especially if that is not the failure response > for setup mode. I can't see a reason that they can't both use the > "cancel" response to indicate that the OP or end user do not wish to

OpenID Exchange

I have made an early draft of a spec called OpenID Exchange on the wiki: The goal of this protocol is to allow user-accompanied HTTP requests. "user-accompanied" means that a consumer makes a request to a service on behalf of a user an

Re: [OpenID] Assertion Quality Extension => openid.importance

Justin S. Peavey wrote: > > I fully agree with you in your example above until you mention money. > In the Amazon example for book purchases, the user is not the one > affected by a mis-authenticated transaction, Amazon and the credit-card > companies are; the user is indemnified by most credit c

Re: [OpenID] Assertion Quality Extension => openid.importance

Manger, James H wrote: > A related hassle is that when my OP supports a new authentication method > (such as a strong password-authenticated key agreement scheme (eg SRP)), > existing RPs will not recognize this method as strong enough for the RP’s > expectations – regardless of the method’s act

Re: [OpenID] Assertion Quality Extension => openid.importance

Paul Madsen wrote: > Is there not a potential contradiction between an RP expressing both of > 'this is very very important to me' and 'I leave it to you as to the > specifics'? > Perhaps, but that is the case in both the "IdP reports" and the "RP suggests" case: either way the IdP is calling

Re: [OpenID] Assertion Quality Extension => openid.importance

Manger, James H wrote: > > The user-centric solution is not for the RP to specify a max auth age (or > captcha or email verification or handbio or hardotp…), but for the RP to > indicate the importance of the authentication. The user (with a little help > from their OP) decides how to react (eg

Re: OpenID IPR Policy Draft

Recordon, David wrote: > > http://openid.net/wiki/index.php/IPR_Policy > Is it really possible to use mailing list subscription as a trigger for a contract like this? The whole idea scares me a little bit, to be honest. It seems more sensible to me to put these restrictions on actual *contrib

Re: Yet Another Delegation Thread

Dick Hardt wrote: > The RP can't trust state that it has sent to the IdP since the > message may have been modified in transit between the RP and the IdP. > > Perhaps someone can explain what state needs to be maintained? And if > the RP wants to put state in the message, I thought we had that

  1   2   >