James Henstridge wrote:
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com 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
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
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
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.
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
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 instead
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
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/specs/openid-simple-registration-extension-1_1-01.html
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 is
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
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 parameter with
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)
-
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 and
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 only
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 MX
SitG Admin wrote:
http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
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 asserting
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
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/
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 and
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
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 the last paragraph
here:
http://openid.net/specs
(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 this case because
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 NAPTR
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 propose
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. For
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
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 try
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 like it
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 identifier but retain one or
more special
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 authenticate as the persistent identifier and the
non
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 the
endpoint URL in the source identifier's XRDS
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 follows the
=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
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 openid.ns.*
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 the
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
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 ask
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
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
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 pairs is a
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 friends
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 think
[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
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 made it
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.net
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
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, make
them
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
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.
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 think as a
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
do discovery on the URI using an appropriate
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 explain
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 of
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
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
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
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
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 arguments,
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 instead
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:
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:
- head start with attributes.
- order of attributes within the
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 xmlns
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 hoping
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 actual
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 card
I have made an early draft of a spec called OpenID Exchange on the wiki:
http://openid.net/wiki/index.php/OpenID_Exchange_1.0
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 and
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
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
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 the
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
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
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 as
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 the IdP has
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 a
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
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
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). So
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 allow
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
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 with names
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 a
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
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 IdP can *say*
83 matches
Mail list logo
