Re: Announcing OpenID Attribute Properties Draft 1

Johannes Ernst wrote: > I thought we had consensus that Drummond and I owned the > vocabularies/ontologies/schema/whatever-we-call-it action item? > The more the merrier, in my opinion. Let the market decide! ___ specs mailing list specs@openid.net h

Re: Announcing OpenID Attribute Properties Draft 1

Johannes Ernst wrote: > > I would agree with you that we should avoid premature standardization > for things that don't have sufficient consensus yet. > > Others argue that it is better to pick one of the alternatives as a > standard, and fix it later if needed, than to not have a standardized

Re: Request for comments: Sorting fields in signature generation

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 message and > not intended to be ope

Re: [PROPOSAL] Removing SIGNALL From Draft 10

Recordon, David wrote: > I believe that > this, minus the parameters in the response being signed, can be achieved > via the "return_to" parameter. Agreed. The return_to URL is normally included in the signature anyway, isn't it? ___ specs mailing li

Re: [PROPOSAL] authentication age

Recordon, David wrote: > No, IdP MUST perform and RP MAY include. > IdP implementations that are embedded into some other app might have trouble implementing this. Take LiveJournal, for example: what should it do in the case where it has to re-authenticate? End the user's LJ session and force

Re: [PROPOSAL] authentication age

Recordon, David wrote: > That was going to be my exact follow-up to my own message, though got > distracted. What I phrased was how Dick described it. > > I like the feature, though agree that many IdPs may be unable to > implement it due to how they do session handling. It could be augmented

Re: One last plea: fix problem with "delegate" terminology

Drummond Reed wrote: > > However, in the two months since I last had that conversation, I've had to > explain the concept of "OpenID delegate" to a bunch more people, and I'm > telling you, STICKING WITH THIS TERMINOLOGY IS GOING TO BITE OPENID IN THE > BUTT!! > > The problem is: the more OpenID

Re: openid.delegate explained.

Josh Hoyt wrote: > > An example to illustrate how delegation can make it hard to understand > what's going on: > > 1. Set up an IdP that will let me verify, say "bradfitz.com." This > does not mean that I have any control of bradfitz.com, just that if I > did, I could use this IdP. > > 2. Set up

Re: openid.delegate explained.

>> And all you've achieved here is to hand your identifier over to Brad. > > Not at all! My IdP will only accept my credentials. If Brad pointed > his identifier to my IdP, he'd have handed it over to me, but there is > no way that he can use MY IdP even though it would make an assertion > about

[PROPOSAL] Separate Public Identifier from IdP Identifier

Currently the conceptual model is that each user has a "public" (that is, presented to RPs) identifier, but can optionally create additional identifiers which "delegate" to the real identifier. The delegate functionality has several purposes, including: * "Vanity" identifiers on personal doma

Re: [PROPOSAL] authentication age

Dick Hardt wrote: > I find the argument that IdPs will just return success all the time > to be baseless. A good IdP will do what it thinks is best for its > users. A bad IdP will not have any users for any period of time. I suppose it depends on what you consider to be "bad". Consider this:

Re: openid.delegate explained.

Dick Hardt wrote: > > The RP needs to resolve the identifier to check who is authorative > for it. > > If you create a mechanism for how to resolve who owns > "mailto:[EMAIL PROTECTED]", then it works. > > That functionality is needed to prevent any IdP from being > authoritative for an ar

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

Dick Hardt wrote: > > I think "Token" is not a good name, so many other meanings. Perhaps > "handle"? > I agree that "token" is not the best name. "handle" is still not that specific, but at least it isn't used in too many other places. (We do already have an "assoc_handle", however.) _

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

Dick Hardt wrote: > I like making all identifiers work the same way. The wording around > directed identity is somewhat confusing. Would be clearer if there > was a complete description of what happened. ie. complete the > transaction. In Directed Identity, the RP needs to do discovery on >

Re: Strong Authencation (was [PROPOSAL] authentication age

Chris Drake wrote: > Hi All, > > 1. Amazon asks the IdP "Please assert this user is not a Robot" >How can it trust this occurred? > > 2. Amazon asks the IdP "Please re-authenticate this user, via >two-factor, two-way strong authentication" >How can it trust *this* occurred? > > The I

Re: Summarizing Where We Are

Dick Hardt wrote: > On 5-Oct-06, at 4:41 PM, Josh Hoyt wrote: > >> On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> I think you missed my message arguing why it was important and that >>> being part of the return_to URL made it hard for the functionality to >>> be contained in the library >>

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

Kevin Turner wrote: >>From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken > (change #3): >> Impact on XRI-based auth: >> >> An XRI is, for this purpose, a URI that can be resolved into a URL at >> which we can do Yadis discovery. Once Yadis discovery begins, flow >> continues as in t

Re: Consolidated Delegate Proposal

Recordon, David wrote: > Dick, > It is needed in the case where there is delegation with a URL, > openid.identity is the actual URL on the IdP and then openid.rpuserid is > the URL that the user entered which delegates to openid.identity. This > is then also used in the similar case with XRI deleg

Re: XRI canonical id question

Johannes Ernst wrote: > Drummond: > > The current auth draft says in section 11.4: > If the Verified Identifier is an XRI, the discovered CanonicalID > field from the XRD SHOULD be used as a key for local storage of > information about the End User. > > Is there ever a scenario where the id

Re: XRI canonical id question

Drummond Reed wrote: > > Right on the money. I would go further and recommend that an RP not even > store the i-name, just the i-number and a user's preferred display name. > That way the i-name becomes really just a convenient way for the user to > give the RP their i-number (CanonicalID). > I

Re: Consolidated Delegate Proposal

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 a >

Re: Consolidated Delegate Proposal

Dick Hardt wrote: > > Given that a Google of the delegate tag will yield all URLs > containing it, > there is no value in hiding delegation anymore. > If I considered it important enough, I could restrict access to my Yadis document to only one party using various techniques, thus preventing

Re: Consolidated Delegate Proposal

Drummond Reed wrote: >> >> I was supportive of keeping the delegate from the IdP until I >> realized that the delegation was public knowledge and could not be >> hidden from the IdP. > > The same argument convinced me, too. If public XRDS documents are what we're > using to provide user contro

Re: [PROPOSAL] request nonce and name

Recordon, David wrote: > > We thus believe that any state tracking needed by a stateless RP must be > maintained as GET parameters within the return_to argument. In the case > of a stateful RP, it can either do the same thing, or store state via > other means such as using a session id within

Re: Consolidated Delegate Proposal

Dick Hardt wrote: > > Won't the IdP will still have to resolve the i-name? The IdP can't > trust the RP, or know that the i-name and i-number are really linked > unless it checks itself. > The IdP is only authenticating the i-number. The i-name is for display to the user and possibly to all

Re: Delegation discussion summary

Graves, Michael wrote: > > > I won't delve into where we are with respect to that capability here, > but want to suggest that maybe as we move to OpenID 2.0, and now offer > portable IDs (as well as run-time chosen IDs selected at auth-time?), we > may be wise to just make the jump to using "home

Re: Delegation discussion summary

Drummond Reed wrote: > +1 to getting it done. This area of terminology is more a > usability/marketing issue at this point. I agree we need to converge on > good, simple user-facing terms for describing OpenID in ways ordinary > Web users can easily understand. Although I have great respect for

Re: [PROPOSAL] request nonce and name

Marius Scurtescu wrote: > On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote: > >> On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: >>> If passing through all unrecognized parameters can cause problems >>> then there could be a special namespace for this purpose. For >>> example, all parameters wit

Re: Identifier portability: the fundamental issue

Brad Fitzpatrick wrote: > > Counter-argument: but OpenID 1.1 does have two parameters: one's just in > the return_to URL and managed by the client library, arguably in its own > ugly namespace (not IdP/RP managed, not "openid.", but something else... > the Perl library uses "oic." or something).

Re: Delegation discussion summary

Dick Hardt wrote: > > I don't think we actually need to have a specific name when talking > to users. it is a site that supports OpenID. I agree. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs

Re: IdP term in spec (was RE: Delegation discussion summary)

Drummond Reed wrote: > Suggestion: sidestep the issue completely and in the spec -- and everywhere > else -- just call it OpenID provider. It's a simple concatenation of > "OpenID" and "service provider", so everyone gets it, but nobody will > associate it with SAML or federation or anything else.

Re: Discussion: RP Yadis URL?

Recordon, David wrote: > > I'm torn if this parameter should be added to the spec at this time or > not. Adding the parameter is conceptually simple, though I don't think > there is agreement on what the RP should be publishing in their Yadis > file. There is the section > http://openid.net/spec

Re: openid.identifier vs openid.identity

Dick Hardt wrote: > Given that the spec uses the word identifier throughout, it would > make sense that the parameter would be called that. > > Perhaps in changing what the parameter contains, we can rename it, > and keep openid.identity for backward compatibility? > I think this a good idea

Re: Identifier portability: the fundamental issue

Chris Drake wrote: > > There seem to be a lot of people on this list who want to hate and > loathe the IdP, and grant all power to the RP. I do not understand > this reasoning: our users will select the IdP they trust and like, > then they will be using a multitude of possibly hostile RPs > ther

Re: Notes From Draft 10

Marius Scurtescu wrote: > > If ordering is not important then you are guaranteed to get it right. > The spec could recommend alphabetical ordering, but I don't see the > need for a must. > I agree. ___ specs mailing list specs@openid.net http://

Re: Question: multiple IdPs?

Dick Hardt wrote: > Forgive my lack of Yadis configuration expertise, but is this > something that your average blogger can add to their WP or MT blog? > As long as the user's IdP is explicitly setting openid:Delegate in their Yadis document, they should simply be able to point their X-Yadis-

Re: PROPOSAL: RP identifier

Dick Hardt wrote: > > The IdP needs a unique identifier for the RP. > openid.realm is a wild card that could match multiple RPs. This was by design. An RP that is exposing multiple "RP endpoints" within the same realm is explicitly saying that it needs/wants them all to be treated the same.

Re: PROPOSAL: OpenID Form Clarification (A.4)

Dick Hardt wrote: > > In order for the RUA to detect that a site supports OpenID, it sees a > form with a single input with a "name" of openid_identiifier. The RUA > can then look at the action and post the data directly to the RP. > I think it'd be better to implement this as either a META

Re: XRI confusion

Dick Hardt wrote: > > How would a user ever learn what their CanonicalID is? The user doesn't need to know his i-number. The system discovers that for him. > If there Portable Identifier (i-name) is reassigned, then they will > be sent to an IdP for the new Canonical ID is, expecting credenti

Re: PROPOSAL: rename Identity Provider to OpenID Provider

Dick Hardt wrote: > > Rename Identity Provider to OpenID Provider in the spec > +1 Agreed. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs

Re: PROPOSAL: RP identifier

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 that they are by definition part of the same RP.

Re: XRI confusion

Dick Hardt wrote: > > Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does > not know this. Bob goes to an RP, enters =foo and gets sent somewhere > he cannot authenticate since =foo resolves somewhere else. > > Bob does not know what to do. =foo does not resolve to his i-numbe

Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))

Drummond Reed wrote: > Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea > notion for a site advertising the location of the P3P privacy policy: it > defined a standard HTML/XHTML link tag that could be put on any page of a > site that told the browser where to locate the

Re: PROPOSAL: rename Identity Provider to OpenID Provider

Granqvist, Hans wrote: > > Why not simply call the idp "idp", and prefix it "OpenID idp" > if context or clarification is needed, all referencing an > OpenID spec def of "OpenID idp"? > While I guess I agree with your objection, I don't like the redundant "ID" in "OpenID IdP". It makes it awk

Re: [PROPOSAL] bare response / bare request

Dick Hardt wrote: > 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 doe

Re: OpenID Login Page Link Tag

Drummond Reed wrote: > I initially agreed as well. But to play devil's advocate, the link-to-XRDS > option could actually be pretty efficient. Any HTML page could simply > advertise the availability of its Yadis XRDS file using an XRDS link in the > header. Assuming that many or all of the pages on

Re: Two Identifiers - no caching advantage

Dick Hardt wrote: > 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

Re: PROPOSAL: RP identifier

Dick Hardt wrote: > > The issue here is that realm is an overloaded parameter. It is being > presented to the user for the user to decide if it wants to IdP to > provide similar results to any RP return_to that matches the > wildcard. It is also being used by the IdP to uniquely identify the

Re: [VOTE] Portable Identifier Support Proposal (patch)

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 in an implementation. > You keep stating that bo

Re: Yet Another Delegation Thread

Dick Hardt wrote: > 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 Ident

Re: Yet Another Delegation Thread

Pete Rowley wrote: > > Actually I think this is a consequence of using URLs as identifiers and > wanting to use my site to host the portable identifiers - you're > probably thinking separate domains per portable identifier or using some > well known IdP. Each identifier can be correlated by inf

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

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: [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] 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: > 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

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

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

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: 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: 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: 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?

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

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

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: [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: [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:

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

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

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

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

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

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

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

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

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

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

[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, > > 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: 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: 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: 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: 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: 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

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

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

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

  1   2   >