Re: Announcing OpenID Attribute Properties Draft 1

[Martin Atkins]

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
http://openid.net/mailman/listinfo/specs

Re: Announcing OpenID Attribute Properties Draft 1

[Martin Atkins]

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 
> facility for an important function (an argument that I understand).
> 
> The current approach seems to be to go down the standardization route 
> and see how far we can go. It is certainly possible that as we go down 
> that route and improve the proposed specs, some of the objections will 
> disappear ...
> 

Oh, I certainly agree that having one standard is a good goal. What I 
don't agree with is in-fighting about who gets to work on various 
things. I'm not so arrogant as to implicitly believe that my ideas are 
better than anyone else's, but that doesn't mean I won't have a go and 
try things out and see how they fare.

If something else turns out to be better (read: more liked by the 
general populace) then so be it, but I don't think anyone should be put 
off contributing a proposal just because someone else has decided that 
they "own" a particular area of thinking.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request for comments: Sorting fields in signature generation

[Martin Atkins]

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 operated on by the application that is processing
> the OpenID request. Basically, to reduce the likelihood of name
> collisions with parameters that the application uses.
> 

An example, just to make doubly sure that everyone knows what's being 
discussed here...

If I have:
http://www.idp.com/server?user=mart"; />

...then when the OpenID request is made, it's important that the 
argument given there is preserved:

http://www.idp.com/server?user=mart&openid.mode=...&openid.cla...

However, the relying party doesn't want that IDP-specific "user" 
argument passed back to it. In fact, it possibly has its own set of args:

openid.return_url=http://www.relying.com/openid?mode=return

...so to avoid conflicts between these unqualified namespaces, I believe 
the IDP should only return back the spec-defined openid.whatever args to 
the relying party.

If the relying party needs to round-trip arguments back to itself, it 
can do that by including them in the openid.return_url value as shown 
above, return_url is included in the response signature.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Removing SIGNALL From Draft 10

[Martin Atkins]

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 list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] authentication age

[Martin Atkins]

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 them to log in again? Duplicate the login code in the 
OpenID server code?

Aside from that qualm, this is another one of those things where it's 
pointless to make it a MUST since IdPs that don't implement it aren't 
going to get punished in any way. If IdPs can get away without doing it, 
and RPs can't tell that they have, then some/most IdPs just won't 
bother. Sure, it reduces the usefulness of this feature, but this 
feature is riding on a completely uncheckable assumption and is 
therefore broken by design.

The best we can do is make it a MAY (that is, max_age is a *suggestion* 
from the RP) and hope that most IdPs do the right thing; we shouldn't 
write the spec in a way that misleads RP implementers into thinking 
they've actually got any real control here.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] authentication age

[Martin Atkins]

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 
> to also contain a response parameter telling the RP if the IdP 
> acknowledged it, then the RP could make the decision if it wants to proceed.
> 

But again, IdPs will just send it whether they did it or not, because 
it's like a "make it work" flag; people will quickly forget/dismiss what 
it really means and set it just to make their IdP work.

Unless you've got some way to *prove* that you did it (I can't think of 
one) there's no point.

This also ignores the fact that not all "IdPs" are going to use sessions 
and passwords. One could potentially make one that acts on a presented 
certificate, for example. Or one which just returns "Yes" to everything 
as an anonymising tool.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 grows, the more folks who are familiar with
> mainstream identifier systems like DNS are going to be exposed to it, and
> the more they are going to go bananas trying to figure out what OpenID means
> by this term "delegate" when essentially the OpenID meaning is the exact
> opposite of what everyone else in the naming world means by it.
> 

I propose simply that openid:Delegate becomes openid:Identifier. This is 
actually a variation on my early proposal for then OpenID bindings for 
Yadis, where I intentionally avoided using the "delegate" terminology.


 http://openid.net/signon/1.1
 http://www.whatever.com/openid
 http://mart.whatever.com/


Perhaps I should have made this more explicit at the time, but my 
thinking here was to separate "the identifier I present to the RP" from 
"the identifier I present to my IdP".

This does change the mental model a bit, but it also makes it more 
consistent and thus, to my mind, easier to wrap your head around. I 
suspect it'd also be easier to explain in the spec. The implementation 
remains the same, of course.

I find this model fits a lot better than the delegation model. In 
particular, it's not possible to cascade "delegations" — that is, you 
can't delegate to another identifier which itself delegates to a third. 
This confused me in the early days. If you think instead of the URI here 
being a "login" for the named IdP, suddenly everything seems to make 
more sense.

Backward-compatibility isn't of great concern here since OpenID 2 is 
presumably going to have its own Yadis service type anyway, so those 
supporting both will need to list both 1.1 and 2.0 Service elements, 
which don't necessarily have to be the same.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Martin Atkins]

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 an identifier, say "j3h.us" to use "bradfitz.com" as a
> delegate, and to use my weirdo IdP.
> 
> 3. Do authentication of "j3h.us" to a RP, and the messages that go
> back and forth will be about "bradfitz.com" and the authentication
> will succeed. The confusing part is that this is the correct
> behaviour.
> 

And all you've achieved here is to hand your identifier over to Brad.


But I agree with you that the delegate identifier might as well just be 
an opaque string per the current spec. This is not inconsistent with my 
post yesterday saying that delegation should be the only case, not a 
special case. There's no disadvantage to this, since the identifier you 
present to your IdP *can* be the same as the one you present to RPs, but 
if delegate is the only mode of operation then it makes the spec simpler 
and thus easier to understand.

(and it no longer needs to be called "delegate", because it doesn't need 
to be called anything other than "the only way to do it".)



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Martin Atkins]

>> 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 /his/ URL.
> 

Okay. I misunderstood your scenario.

Now that I understand what you mean, this makes me think all the more 
that the current "delegate" identifier should just be "token I log into 
my IdP with" and have no other meaning. I'm not really bothered about 
whether it remains a URI or just becomes some opaque string.

The nice thing about separating these two issues is that, even if we 
retain the requirement that this be a URI, it doesn't need to be a 
resolvable URI. I could give "mailto:[EMAIL PROTECTED]" to a hypothetical 
IdP that identifies users by email addresses, for example.

Now that I've collected my thoughts a bit more I'll post this as a 
top-level proposal and stop clogging up this thread with my rambling. :)

Cheers,
Martin

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

[PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

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 domains while letting someone else 
do the hard work in running the IdP.
  * Ability to switch IdPs without losing identity

However, experience has shown that the above model is often difficult to 
grasp for those new to OpenID. This proposal is really just a set of 
terminology changes and an alternative conceptual model that aim to make 
the delegate functionality easier to understand. It does not change the 
mechanism of delegation at all, though it does change the discovery 
protocol.

I've placed the full proposal on the OpenID wiki:
 


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] authentication age

[Martin Atkins]

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:

* We have an RP that asks for a session age limit of one hour.

* GoodCitizen-IdP respects the session age thing and asks user to log in 
again if it's been over an hour since they last did so.

* BadCitizen-IdP just ignores the flag and has sessions that last until 
the user closes his browser, but it lies to the RP and says that it 
respected the flag.

The user experience on GoodCitizen-IdP is "damnit, why do I have to keep 
logging in over and over again?!". The user is likely to be much happier 
with BadCitizen-IdP because he only has to log in once each day.

While it's true that BadCitizen-IdP might put its users at more risk, 
it's been my experience that users are willing to trade an awful lot of 
security to avoid software nagging at them repeatedly.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.delegate explained.

[Martin Atkins]

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 arbitrary URI.
> 
> -- Dick

The public URI is still resolvable by the RP as is necessary.

But the RP never uses the openid.delegate value; it simply passes it on 
to the IdP where the IdP can then do what it likes with it. In 
LiveJournal's case, it's simply a regex to see if it matches 
http://([a-z0-9\-]+).livejournal.com/, which could easily be 
mailto:([a-z0-9\-]+)@livejournal.com, or anything else.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

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

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

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  
> the identifier provided to make sure the IdP is authoritative for it.
> 

Perhaps I've misunderstood how directed identity works, but I figured 
the flow would work as follows:

* The RP initiates Yadis discovery on http://anon.myidp.com/

* The IdP returns a document naming its authentication endpoint (in the 
"URI" field) and a special anonymous token as openid:Token. openid:Token 
may be the same as the public identifier from the previous step, but 
this is not required.

* The RP initiates OpenID auth to the named endpoint using the openid:Token.

* The IdP notes that the special "anonymous" token has been used, but it 
knows who the remote user is (via Cookies, for example) so it can 
generate an identifier and remember that it belongs to that user/RP combo.

* IdP responds to RP with the generated public identifier (which *is* 
publically resolvable, of course.)

* RP resolves the IdP-provided public identifier, where the IdP will 
provide for Yadis discovery and specify that it is authoritative for 
that URL.

* We're done.

The important thing is that, just as I've separated the public 
identifier from the IdP token (or handle, if you like), this separation 
also applies to the IdP-generated public identifier.

(sorry that this is a bit rough. I've not really spent the necessary 
amount of time preparing the above and I'm in a hurry, so if there are 
spots where I'm not clear I apologise and I'll clarify later! :) )

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Strong Authencation (was [PROPOSAL] authentication age

[Martin Atkins]

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* it did, but would RPs prefer a "stronger" role to
> encourage adoption? (eg: #1 - the RP provides the captcha, and the
> hash of the solution, while the IdP returns the solution, or #2 - the
> RP provides a nonce and later looks for this nonce in the IdP's
> also-signed-by-the-authentication-vendor-technology response)
> 
> i.e.: It might get ugly to try and add this stuff in later if we've
> not catered up-front for these kinds of interchanges.
> 

These use-cases seem like a good one, in that it's something that's 
actually *verifiable*, rather than relying on a trust relationship that 
probably doesn't exist between RP and IdP.

I still don't think this should be in the core spec — core OpenID Auth 
should be simple — but we should make sure that it's possible to add it 
via extension and if it isn't adjust the way extensions work to make it 
possible.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Summarizing Where We Are

[Martin Atkins]

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
>> I'm not sure I buy this reasoning, since our OpenID 1 libraries add a
>> nonce to the return_to URL (which is not hard, since the library needs
>> to add stuff to the return_to URL anyway)
> 
> curious as to why the RP library needs to add stuff to the return_to  
> URL? Does it need to for a OpenID 2.0 call?
> 

One example that springs to mind is that the original Perl OpenID 
library would, in the delegation case, put the user-supplied identifier 
in a return_to argument so that it could use that identifier when 
authentication succeeded.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

[Martin Atkins]

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 the original proposal, where openid:Token can be any
>> URI.
> 
> It's unclear to me whether you intended this to be a change from the
> current specification or not, but it is.  Yadis discovery on URLs
> resolved from XRIs is considered redundant, as there's nothing about
> Yadis discovery that can't be done while resolving the XRI.  Since Yadis
> uses the XRI resolution response format, you even get to use the same
> code.
> 
> So was it your intention to add an extra layer to discovery here, or
> should the above section be reworded?

Sorry. That was sloppy.

I did not intend there to be any change at all. By "Yadis discovery", I 
only meant to say that the RP would look for the relevant service element.

My intention for this proposal has always been to not change anything at 
all beyond terminology, with the exception that openid:Delegate (which 
now has a new name) is required. I only changed it to required to 
reinforce the fact that it is distinct from the public identifier, and 
thus (hopefully) to make the spec easier to understand by removing a 
special case.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consolidated Delegate Proposal

[Martin Atkins]

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

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 
stateful RP to hide the real identifier behind a meaningless session 
token, which satisfies Brad's criteria that the RP should be able to 
hide from the IdP the fact that delegation is in use.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: XRI canonical id question

[Martin Atkins]

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 identifier is disassociated from the 
> CanonicalID? I was wondering whether there is a potential security hole?
> 
> [I simply don't know, so I'm asking you ;-) ]
> 
> 

I'm pretty sure that "i-numbers" are never re-assigned. That's a pretty 
fundamental design principle for XRI, as I understand it.

RPs should ideally be displaying the entered i-name but using the 
i-number as the primary key. Of course, this does have the possibility 
that in future the display name may be wrong, but since the RP should be 
storing both it will be able to detect during auth that the two have 
become detached and create a new conceptual user, probably 
disassociating the i-name from the old one in the process.

This does pose a problem to humans in that the RP will be displaying an 
incorrect i-name until the new owner tries to authenticate with the same 
RP, which may never happen.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: XRI canonical id question

[Martin Atkins]

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 agree that sites should just display a preferred display name for each 
user, but that name needs to initially be set to something, since 
bothering the user to enter a display name when all he wants to do is 
sign in is a bad idea, in my opinion.

The simple profile extension can supply a reasonable default, but where 
that isn't available the supplied i-name makes a much nicer default than 
the i-number.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consolidated Delegate Proposal

[Martin Atkins]

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
>> stateful RP to hide the real identifier behind a meaningless session
>> token, which satisfies Brad's criteria that the RP should be able to
>> hide from the IdP the fact that delegation is in use.
> 
> see [1] where I addressed this question. I think that the benefits of
> having it there outweigh the benefit of hiding your identifier *from
> your chosen IdP*. The benefits for having it available to the IdP are
> the same as the benefits outlined in [2].
> 

Trusting the IdP to do one thing (authenticate you) does not imply that 
you trust the IdP to do all things (for example, to know the identifier 
you used on a particular site.)

While it's true that the IdP will know what RPs you have been signing 
into (based on the return_to URLs) it will not necessarily be able to 
track *what you do* on that site unless it knows what identifier you 
used there. In sensitive situations, one can use a throw-away identifier 
that resolves only once and which only the RP need know about without 
IdP involvement.

Giving each party only the information it absolutely requires is a good 
general design principle, in my opinion.

I'm not convinced that the directed identity case needs to work with 
delegated identifiers, but even still there's nothing to stop an IdP 
from giving the user the *option* of disclosing their delegated 
identities through a configuration setting, thus giving the user the 
choice about whether to trust the IdP with this information.

I'm surprised that our resident privacy advocates aren't making a bigger 
deal out of this. (If the privacy advocates have no problem then I'll 
let this go, since this isn't a use case I feel particularly strongly 
about myself.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consolidated Delegate Proposal

[Martin Atkins]

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 
search engines and the IdP from reading the data inside.

Admittedly, this is a lot more effort than most users are likely to go to.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consolidated Delegate Proposal

[Martin Atkins]

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 control of identifier synonyms and thus provide
> identifier portability -- which is the clearest and cleanest approach we've
> seen -- then the best thing we can do from a privacy perspective is not
> mislead users that they are protecting their privacy by using a "public"
> OpenID identifier and a "private" identifier with their IdP.
> 

Fair enough. I'm convinced.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] request nonce and name

[Martin Atkins]

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 cookie to reference 
> database data.
> 

Sounds good to me.
+1.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consolidated Delegate Proposal

[Martin Atkins]

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 the user to choose that as the display 
identity to send back to the RP. The only attacks possible are:

* RP tries to "fool" the user into authenticating as a different 
i-number by sending a false i-name. I'm not sure what the benefit of 
this attack would be for the RP.

* The RP tries to convince the IdP to send back an incorrect display 
identity back in the response. But then the RP is just fooling itself!

The spec should probably contain some words to say that the IdP should 
not do any processing on the public identifier (whether it be a 
delegated HTTP URL or an XRI) that relies on the i-name to i-number 
mapping without first ensuring that the mapping is correct; any such 
processing would be outside of what is required for the Auth spec, though.

Assuming for the moment that we've conceptually "separated the public 
identifier from the IdP token" per my proposal, the public (delegate) 
identifier or i-name is for the RP (it checks the mapping), and the IdP 
token (which is some URI that doesn't necessarily even have to be 
resolvable) is for the IdP. Both parties validate their own token; if 
either party doesn't validate its own token, it opens itself up to the 
other party telling lies. However, they do not have to authenticate 
*each-other*'s tokens.

The RP's validation of its own token is defined by the spec. The IdP's 
authentication is not defined by the spec; the IdP doesn't necessarily 
even have to resolve its own tokens, but it can do if it wishes.

>> Lastly, in the case where the identifier-the-RP-stores and the
>> identifier-the-IdP-stores are different, if the RP has already  
>> discovered
>> the latter, then the RP can be stateless by sending both to the  
>> IdP, knowing
>> it will receive both back in the response.
> 
> Then the RP is trusting the IdP will send back a correct mapping.

This one bothers me too. Unless the RP can sign its initial request 
parameters to stop the IdP from tampering with them, I don't see how the 
RP can trust the IdP to return a correct mapping.

My old stateless RP demo implementation just re-resolved this stuff when 
it got back the response to make sure that the IdP was telling the 
truth. I'd love to hear that this was unnecessary, since it did double 
the identity resolving overhead.


> This discussion has me wondering about XRI resolution though. Given  
> that multiple i-names can resolve to the same i-number, just as  
> multiple domain names can resolve to the same IP address, and that  
> the i-name is the identifier the user sees, it would seem tht the i- 
> name is what should be stored by the RP, otherwise there is no  
> difference between using any of the i-names that resolve to the same  
> i-number, or is that the idea?

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically "throw-away" cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be "expensive" (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Delegation discussion summary

[Martin Atkins]

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 "homesite" and "membersite"
> across the board, rather than "IdP" and "relying party", both of which
> are technically problematic for our framework.
> 

I kinda get "homesite", but I don't understand the thinking behind 
"membersite": What is this site supposed to be a "member" of?



Personally, I quite liked the old OpenID term "consumer". :)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Delegation discussion summary

[Martin Atkins]

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 Dick 
> & Sxip’s pioneering work in this area, I don’t believe terms that use 
> the word “site” are the right metaphor, and the concept of “membersite”, 
> while good for the context Sxip originally used it, would send the wrong 
> message about OpenID.
> 
>  
> 
> But I suggest we move that terminology discussion to the marketing list.
> 

What marketing list?

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] request nonce and name

[Martin Atkins]

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 starting with openid.pass. should
>>> be ignored by the IdP and passed back to the RP.
>> Yahoo Browser-based authentication [1] has a single parameter called
>> "appdata" (that you can find in [2]) that is used for this purpose.
>> This seems general enough to me.
> 
> True, even one single pass through parameter should do.

This causes the minor inconvenience that the RP will probably now have 
to implement its own parsing, rather than using the framework's 
pre-supplied functions for dealing with urlencoded query strings.

Not a major deal, but I'd guess that this is where the idea to use 
return_to args came from in the first place.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Identifier portability: the fundamental issue

[Martin Atkins]

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 then it's harder to
> document the correct behavior to people ("RPs should verify the mapping
> when you get a signature!") because the parameter names aren't consistent
> between RP clients.
> 

Not specifying it gives RPs the freedom to put whatever handle they want 
in the return_to, though. If they *are* able to maintain state, they 
might have some arg like ?handle=1380a383198bcefd933, which is 
completely opaque to everone except the RP.

I'd rather avoid specifying things we don't need to specify, since it 
leaves more flexibility for implementors in an area where this 
flexibility doesn't do any harm.



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Delegation discussion summary

[Martin Atkins]

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)

[Martin Atkins]

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

This seems sensible.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Discussion: RP Yadis URL?

[Martin Atkins]

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/specs/openid-authentication-2_0-10.html#anchor42 which
> has the RP publish a return_to URL, though the section was meant to be
> removed as that URL may not be the right entry point to start a
> transaction.
> 

I would say that what's inside the Yadis document is outside the scope 
of OpenID Auth. It's simply a hook to enable extensions that must be 
instrumented at the RP side.

In other words, OpenID auth just needs to specify how to find an RP's 
Yadis document. The rest is for other people to figure out. That is the 
point of Yadis, after all.

(and then this IdP-initiated login thing could be an extension built 
upon this ability, and thus not hold up Auth 2.0.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: openid.identifier vs openid.identity

[Martin Atkins]

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, but I'm unsure as to specifically what you are 
changing here. Are you talking about the link rel=""? And if so, isn't 
that now being replaced by Yadis discovery?

I think we've got a lot of work to do if we want to change *all* 
instances of "identity" to "identifier" (where that change is 
appropriate, of course.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Identifier portability: the fundamental issue

[Martin Atkins]

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
> thereafter: the reverse is simply not true.
> 

If I'm using one IdP to assert my primary public identity, they can 
hypothetically develop quite a profile about me. I probably don't mind 
too much in most cases, because I researched them and found that they 
are a good provider and won't sell my data out to the bad guys.

However, there might be some things I want to do (for example, posting 
locally-prohibited speech on a public forum) that I don't want attached 
in any way, shape or form to my public identity. The trust relationship 
I have with that IdP probably isn't enough for this; if there is any 
record at all of any association between these two identities, as 
friendly as my IdP may be, there is a chance that it will be ceased by 
court order, or leaked by an insider, which might lead to me getting in 
serious legal trouble.

This is just one (perhaps extreme) example of why my trust in my IdP is 
not universal and all-encompassing. Trust is not a boolean.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Notes From Draft 10

[Martin Atkins]

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://openid.net/mailman/listinfo/specs

Re: Question: multiple IdPs?

[Martin Atkins]

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-Location at, say http://user.livejournal.com/data/yadis [1] and 
have things work without having to write a Yadis document.

Of course, their WP or MT blog will then inherit all of the service 
declarations exposed by the IdP, some of which might not be as easily 
"delegatable" as OpenID is.

(This cross-domain linking is another reason why openid:Delegate should 
be required, incidentally.)



[1] LiveJournal doesn't actually explicitly set openid:Delegate, so it 
is perhaps a bad example. This can be fixed if it proves worthwhile, though.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: PROPOSAL: RP identifier

[Martin Atkins]

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.

Part of this design is the ability for the RP to move the "RP endpoint" 
to a different URL without breaking all existing relationships, which is 
an important requirement in the real world where people often expose 
their underlying architecture in their URLs and then have to break the 
URLs when the architecture changes.

The realm (assuming that this is what used to be called trust_root) is 
what you should be using, and *allowing* that to match multiple RP 
endpoints is okay and desirable.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 or a LINK 
element alongside a standard protocol for communicating with the 
nominated URL.

This way the site can declare on *all pages*, rather than on the 
forms-based login page, that it accepts OpenID auth. This allows the 
user to go to the RP's home page (or any other page) and click the 
"OpenID Login" button on the browser's toolbar and have it work.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: XRI confusion

[Martin Atkins]

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 credentials  
> from the new owner. The user will never make it back to the RP, and  
> they will have no easy way of proving they are the owner of the  
> CanonicalID.

I don't really understand this paragraph, but when the i-name is 
reassigned it'll cease to point at the same XRDS and will thus not point 
at the IdP anymore — unless the new owner also has an account with that 
IdP, of course. But they have a different i-number, so the IdP can 
distinguish them.

> Additionally, in the proposal, the i-name is not sent from the RP to  
> the IdP, so how does the IdP know which i-name to address the user  
> as?

I would hope that an IdP, given that I've already established a 
relationship with it, can find something better to address me with than 
a URI. It should be calling me "Martin".


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: PROPOSAL: rename Identity Provider to OpenID Provider

[Martin Atkins]

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

[Martin Atkins]

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.

This does raise the question of what to do when one realm exists inside 
another, but I suppose the most obvious answer is to select the most 
specific of the available options — that is, the one with the least 
"wildcardy-ness"[1]. Someone probably should define precisely how the 
specificity of realms works if it isn't in the spec already.



[1] Now *that* is a good word!

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: XRI confusion

[Martin Atkins]

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-number  
> any more. How does he find out what it is so that he can get a his i- 
> name to point to it?
> 

This is up to the registrar (i-broker, I think?). Presumably they'll let 
Bob know that he's let his registration lapse and that it can now be 
registered by someone else. Bob will be unable to reclaim the i-name 
unless Alice is willing to release it to him. Bob's i-broker presumably 
knows what Bob's i-number is and so if he does re-obtain it they will 
point it on his behalf.

This is just general administration stuff, out of scope of the 
protocols. It's not much different in principle to a hosting provider 
that sells you a domain name and a bundled website. You don't need to 
know the IP address of their web server because they set up that mapping 
for you. If you let your registration of the domain lapse, they'll 
presumably let you know.





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 P3P policy document for the
> site (or for any portion of the site).
> 
>   http://www.w3.org/TR/P3P/#ref_syntax
> 
> Are you proposing the same thing for OpenID login?
> 

Yes, that is the idea. I don't have time at this moment to write out a 
full proposal, so I'll just quickly summarize/ramble...

Right then. On any page of the RP, they can write:

http://www.mysite.com/openid"; /> [1]

Now, if we make to that URL the same kind of request that a return_to 
URL expects to receive, the RP has almost everything it needs to get 
going with the request. Unless I've missed something, all it's missing 
is the public identifier the user has selected — what he would have 
entered into the form under normal circumstances. So we define an extra 
parameter oirp.identifier to carry that. Now with only minimal changes 
to the RP we have an interface that a clever client can use to login 
without forms.

This just leaves the rich client to IdP communication. As I noted in a 
similar message on the other mailing list, this doesn't actually *need* 
to be a standard at all — the IdP could just issue a plugin which works 
only with that IdP. That's a lot of duplication of work, however. So 
what we need is another standard protocol by which the rich client can 
request a signature; the input argument is the IdP Token, or 
claimed_identity as the auth spec calls it.

Since there has thus far been no communication between RP and IdP, "dumb 
mode" must be used; the IdP returns a signature and a handle to the rich 
client, which it then sends on to openid.rp as described above. The RP 
can then resolve the presented identity to find the IdP and validate the 
signature.

This is really just a variation on the HTTP auth proposal. The 
differences are:
  * Rich client passes args to RP via query string rather than 
WWW-Authenticate header.
  * We actually specify a protocol for the communication between the 
rich client and the IdP, unlike my HTTP auth proposal which left that 
out of scope. Note that HTTP auth can potentially make use of this 
protocol too.
  * There's a separation between the URL where you discover the OpenID 
support and the URL where you make use of it. With HTTP auth, you just 
make a request and get back a 401 Unauthorized, or you just "know" the 
URL ahead of time.

Really, the above could use the HTTP auth protocol to talk to the RP's 
endpoint, but I selected the above because it makes the required RP 
changes much simpler — just support an extra argument in your return_to 
handler.

[1] This is just an example. We'd probably use Yadis in practice, since 
that would give us versioning for free and the ability to add other 
services. However, this would make implementation marginally harder for 
plugin developers as they now need to do more than just grovel around in 
the DOM of each page as it is loaded, and it'll create an extra overhead 
for any page that has an X-Yadis-Location, regardless of whether this 
particular service is listed. I'll leave it to others to debate whether 
to use Yadis, a custom LINK REL, or some META element.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: PROPOSAL: rename Identity Provider to OpenID Provider

[Martin Atkins]

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 awkward to say out loud, if nothing else.

Perhaps we can say its full name is "OpenID Authentication Provider", 
but shorten it to just "OpenID Provider" when the context is obvious? 
(or just call it an AP and have done with it?)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] bare response / bare request

[Martin Atkins]

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 does not need the IdP to send the user back, a bare request  
> is needed.
> 
> 
> Proposed Implementation
> ---
> bare request: if the openid.return_to parameter is missing or blank,  
> then the IdP will not send the user back to the RP
> 
> bare response: sending a bare response is valid (not sure we need to  
> do anything more then say it is OK to do)

It sounds to me that this "bare response" thing is just a special case 
of the "rich clients" we're discussing right now in a separate thread. 
The IdP is just using redirects to make a dumb browser act like a rich 
client.

If rich clients were implemented in the way I've been promoting [1], 
IdPs would then be able to make use of the same mechanism.


[1] http://openid.net/pipermail/specs/2006-October/000596.html

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Login Page Link Tag

[Martin Atkins]

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 site would be covered by
> the same XRDS file, the browser would only need to download it once to cover
> the entire site. The XRDS would expire (using the same cache control that
> XRI resolvers use) and be refreshed as needed.
> 
> This is the architecture that P3P used
> (http://www.w3.org/TR/P3P/#ref_syntax). 
> 
> The XRDS file could provide discovery of multiple services representing the
> RP, not just the login page.
> 

This is not incredibly different to what happens when you have a 
site-wide CSS stylesheet. In fact, it is possibly *better* than that 
situation since you don't need to delay page rendering while waiting for 
the Yadis document to download.

I wonder, though, whether we are asking too much of browsers' plugin 
interfaces? This is an honest question, as someone who's never written a 
browser chrome plugin before.

I guess IE's ones are just COM objects and can thus do whatever they 
like, but what of Firefox? Chrome overlays? Does that mean that they can 
access the HTTP component somehow to make HTTP requests?

I think Opera's pretty unlikely as it has no real plugin interface to 
speak of. I have no idea at all about Safari.

Anyone care to elaborate? There's no point in speccing something that's 
unimplementable, but it's probably okay as long as IE and Firefox can do 
it; the others can just catch up later.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Two Identifiers - no caching advantage

[Martin Atkins]

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 mapped
>> This is the part where I think you're wrong. The RP MUST verify that
>> binding, whether it is by keeping state, self-signing the request
>> (which gets passed through to the response) or doing discovery again.
> 
> I agree the RP SHOULD do that. The proposal does not specify that.
> I thought we had that conversation. I have not looked at the patch  
> that you sent. Perhaps you address the issue there.
> 
> My point though is: why have the RP bind the IdP-specific identifier  
> and the public identifier? Why not let the IdP be responsible for this?
> 
> In 1.x when the IdP was not aware of the public identifier, then the  
> RP had to do the binding. Now that the IdP is aware of the public  
> identifier, it would be simpler and logical for the IdP to be  
> responsible for the binding. It is doing it anyway.
> 
> All the RP wants is which public identifier is the user, and is the  
> IdP authoritative for it.
> 

If "delegation" is going to require cooperation from the IdP anyway, 
there's no longer any value in having the distinction between a public 
identifier and an IdP-local identifier. The hypothetical IdP 
"IdP-tastic" can just store a relationship between 
http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's 
no need for http://mart.idp-tastic.com/ anymore, and with that gone 
delegation is no longer useful: the public identifier, whatever it might 
be, is the only identifier.

Any disadvantages to uniting the public identifier and the IdP 
identifier are also disadvantages of having the IdP do the "binding" as 
you describe. For simplicity's sake, I'm currently only willing to vote 
positively for one of the following scenarios:

* Have only one identifer in the protocol. Remove delegation entirely. 
IdP maintains relationships between arbitrary identifiers and its local 
user accounts. IdP no longer needs to issue its own identifiers, though 
it can if desired. This makes life simpler for RPs, but has the risk 
that delegation would become an IdP "premium" feature, which may hurt 
users in the long term.

* Protocol has two distinct identifiers: public and IdP-local. Relying 
party manages delegation. IdP does not even know that the delegation has 
taken place and has no way to stop it happening [1]. RP now has to do 
more work, but identifier portability now comes for free.

Having the IdP deal with the public identifier while still keeping the 
IdP-local identifier (and thus delegation) is, it seems to to me, 
muddled nonsense; the whole purpose of delegation was to make these 
identifiers distinct.


[1] Conceivably a mischievous IdP could make use of knowledge of how 
particular RPs round-trip their delegation state to block it, but that 
would be an arms race in the RP's favour rather than a designed-in 
mechanism for detecting delegation.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: PROPOSAL: RP identifier

[Martin Atkins]

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

Those two seem to be the same thing to me.

The user says to the IdP "Sure, tell this RP that I'm me and don't ask 
me next time." IdP remembers that preference based on the realm. That 
preference is keyed on the realm, and thus the realm *is* the unique 
identifier, in a funny sort of way.

You seem to be conflating "relying party" with "relying party's 
return_to URL". LiveJournal is a relying party with a realm of 
http://*.livejournal.com/; it may well have multiple return_to 
endpoints, but they all belong the same relying party. Any settings the 
IdP keeps for that [user, relying party] pair should apply to all 
endpoints inside that realm. [1]


[1] Unless of course an RP with a more specific realm exists inside 
LiveJournal's. It's debatable whether settings applied to LiveJournal 
should be inherited by RPs with sub-set realms. Shall we debate this? :)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 both the RP and the IdP are verifying this, but 
under 1.1 at least this is not the case: the RP verifies the delegation, 
and the IdP is completely unaware of it. There is no need for the IdP to 
verify the delegation, since the RP will only harm itself if it fails to 
verify the relationship correctly.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Yet Another Delegation Thread

[Martin Atkins]

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
 Identifier, the RP can send the IdP-Specific Identifier to the IdP
 and save
 the IdP from having to repeat discovery.
>>> unfortunately that disco information could be modified in route, so
>>> the IdP can't trust it
>> I have said this several times already, but THE IDP DOES NOT HAVE TO
>> TRUST THIS INFORMATION.
> 
> Then why send it?

That's what I've been asking all along! :)

What exactly do we imagine the IdP doing with the claimed_identifier? 
The main answer I've seen anyone post so far is that the IdP will use it 
to greet the user, but:
   * If it's only used for display, the IdP doesn't really need to check 
it since the user or RP is only fooling itself.
   * I would expect my IdP to greet me as "Martin", since I've 
registered with them and so they presumably know my name. Even if they 
don't have a record of my name, there's no point in parroting back to me 
whatever I just typed into the login form! [1]




[1] 10 INPUT "What is your name?"; N$
 20 PRINT "Hello, "; N$; "!"


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Yet Another Delegation Thread

[Martin Atkins]

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 inference in this 
> case since they are on the same site. Non-correlatable identifiers would 
> need to either be on separate sites or be hosted as a service and 
> thereby taking advantage of the "lost in the crowd" effect.
> 

This is true, but this is an implementation decision you can make for 
yourself. If you want to make an identifier that has no links to any of 
your other identifiers, there's no reason why you can't choose to use an 
arbitrary IdP-issued identifier that has no connection with any others. 
You lose the identifier portability, but this is a trade-off you must 
make on your own.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Yet Another Delegation Thread

[Martin Atkins]

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  
> data in the return_to? The RP likely needs to sign that in some  
> manner to know that it was not modified as well.
> 

The current stateless RP implementations just repeat discovery when they 
get back the signature. There is therefore a slim chance that the 
request had been modified to change the claimed_identity to another 
identifier owned by the same user and delegated to the same IdP 
identifier at the same IdP. However, aside from this rather odd attack 
the second discovery is sufficient to avoid the need for RP state or 
signatures.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID IPR Policy Draft

[Martin Atkins]

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 
*contributions*: require that any proposal or concrete 
specification/implementation offered via the mailing lists or other 
"official" channels to come with patent disclosure, and only *then* are 
any undisclosed patents assumed to constitute a royalty-free, perpetual 
licence.

As it is currently written, I think lots of companies that retain 
software patents of any kind — or even ones that don't but may wish to 
in the future — would be put off contributing due to the risk that their 
patents may be implicitly licenced to everyone.

I'm not a lawyer, of course. However, not everyone who could potentially 
be affected by this is a lawyer either, so putting in stuff that 
potentially scares non-lawyers like myself is probably a bad idea.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 whether or not to login again) based 
> on the importance/RP/auth-age/….
> 

I like this approach a lot more. It seems a lot more honest as to what's 
really going on, and it leaves protecting the task of user's interests 
in the IdP's hands where it belongs.



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 shots, but the "RP 
suggests" case is more honest about who is in control.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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

Consider also that non-human agents can often be both the OP and the 
"user" at the same time (they specify a URL under their own control as 
the OP, generate their own signature and respond) and in this case the 
OP knows that the user is the user without any shadow of a doubt because 
it *is* the user. However, this scenario would fail in any situation 
where a particular authentication scheme is demanded because there is 
*no* traditional authentication in this scenario.

However, if the RP instead presents (for example) a list of keywords 
identifying (in vague terms) what is at stake:
 transaction_involves=money+personal_details

...my non-human agent can pick up that it's being used for something for 
which it is not intended and refuse to take part. My traditional OP, on 
the other hand, can present me with a set of options (with reasonable 
defaults) for what to do in the presence of these keywords so that 
anything involving money can force a re-authentication (again, for example).

Whether a list of keywords is the way to go remains to be seen, but I 
believe this is the most sensible approach in principle.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 companies for
> fraudulent purchases.  If the user was *actually bound* to be
> responsible for the transactions their identities perform, the model
> works - but this is not the world that I (or Amazon, or Bank of America)
> live in. 

Is anyone really expecting an OpenID identity to be used in place of a 
credit card number? Perhaps I'm just not seeing the advantage of this, 
but I would expect that most organizations carrying out credit card 
transactions would:

  * Use OpenID to authenticate the user against the account to gain 
access to the purchase history, returns, enquiries and such.
  * Demand the user's credit card before actually performing any 
transaction.

While I'll admit that Amazon and PayPal currently store credit card 
details and require (in some cases) only the password to be entered, it 
can hardly be argued that my Amazon password is any more secure than my 
IdP password. In Amazon's case they still don't let you make a purchase 
knowing only the password in most cases; you have to provide all or part 
of the stored credit card number or other authentication details.

But this is all beside the point given the fact that the OP *is always 
in control* — there is NO WAY that the RP can tell what the OP really 
did. The OP can lie, the OP can have a bad implementation of a given 
authentication scheme or the OP might not even be a traditional OP at 
all. I don't really see the value in presenting a protocol which gives 
an illusion of control to the RP; it just seems dishonest.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID Exchange

[Martin Atkins]

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 and the user reviews and approves the request.

Example applications of this include:
  * Zooomr posting photos into your blog with your one-time approval, 
without disclosing your login credentials. [1]
  * Fetching of user profile information.
  * Social networking friendship handshakes. [2]

The protocol should, in theory, be able to act as a transport for any 
HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET 
requests. The protocol for "post in my blog" could, for example, just be 
an AtomAPI POST request made over OpenID Exchange.

This is still work-in-progress. The spec needs lots of refinement and at 
some point I'll have to make a demo or two.

[1] You can still see the results of the demo of my earlier version
of this on LiveJournal, albeit without the pictures:
 

[2] Discussed further in my blog entry on social networking:
 


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Consistency of negative responses to checkid_immediate requests

[Martin Atkins]

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
> complete the transaction.
> 
> This is a very minor change, but it will make the spec simpler.
> 

I think the RP will want to do something different in these two cases. 
In the "cancel" case (which indicates that the user cancelled the 
request in some way) the RP will probably return to the login form to 
invite the user to try again.

In the checkid_immediate case, what needs to happen is that the RP must 
start a checkid_setup request instead, since a negative response in the 
checkid_immediate case generally means "I can't answer this until I've 
presented some UI to the user".

I suppose it could be argued that the RP should know what it's doing and 
be able to distinguish between these cases using its own state, but 
given that the meaning of these responses is different I don't think 
it's a problem that the messages are different.

It'd might be nice if the checkid_setup error response were called 
something other than "id_res", though.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Exchange

[Martin Atkins]

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 to get some working demo examples done this weekend in some 
form or other, if I get time. Failing that, I'll at least try to get 
some written, theoretical examples written up for the scenarios I listed 
in my original message.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID.net Service Type Namespaces

[Martin Atkins]

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 for the
> Auth 2.0 spec itself, since unlike the 1.1 spec which defined
> "OpenID:Delegate" in Yadis, 2.0 takes advantage of the "LocalID" element
> already defined in the XRD schema.

I missed the change to using LocalID. I'm glad to see that change, but 
really just because I've always hated the fact that it was called 
"Delegate" in Yadis. :)

 > http://specs.openid.net/extensions/ABBREV/VERSION

This naming scheme doesn't separate out extensions by what they're 
extending. Presumably in future we're going to have other non-extension 
specs (that is, they don't actually use the OpenID Authentication 
request as a transport) which will themselves have extensions.

How about,

http://specs.openid.net/authentication/2.0/exten/simplereg/1.0

I've not got my heart set on abbreviating "extensions", but I don't 
really like URLs that are longer than one line in a plaintext email 
because then people start wrapping them over multiple lines. :)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Martin Atkins]

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, and the value associated with the
> | key. The line is terminated by a single newline (UCS codepoint 10,
> | "\n"). A key or value MUST NOT contain a newline and a key also MUST
> | NOT contain a colon.
> 
> While it's ok for keys to have a limited alphabet, not allowing them in
> the value may be a problem for future extensions (say, if AX wants to
> transfer a multiline postal address).
> 
> I don't think it's a good idea to invent a new format here. What's wrong
> with URI percent-encoding, which has to be implemented by OpenID
> software anyway?
> 

As far as I'm aware the protocol does not allow for extensions to add to 
the messages sent in this encoding. Extensions are only allowed to take 
part in the messages passed by redirecting the UA, in urlencoded format. 
The OpenID protocol itself has no need for newlines or other fancy 
characters here.

I agree with you that inventing a new format here was an odd choice, but 
unfortunately it's already in use by deployed OpenID 1.1 implementations 
and so OpenID 2 implementations will have to support it anyway.

> 
> | The response body MUST be a Key-Value Form (Key-Value Form Encoding)
> | message with the following fields:
> ...
> | *error
> | Value: A human-readable message indicating the cause of the error.
> 
> What about different languages?
> 
> This is actually tricky. The Accept-Language header from the user is not  
> available to the OP if it is contacted by the RP directly, so the OP  
> can't choose an appropriate language.

This "human-readable message" is really addressed at the developer of 
the non-compliant implementation, not the end-user. Therefore support 
for multiple languages was thought not to be that important. All current 
implementations use straightforward English messages.

The end-user should never see such a message since these error responses 
only arise when there is a bug in someone's implementation. (In theory, 
at least!)

> 
> | 7.3.3.  HTML-Based Discovery
> |
> | HTML-Based discovery MUST be supported by Relying Parties. HTML-Based
> | discovery is only usable for discovery of Claimed Identifiers. OP
> | Identifiers must be XRIs or URLs that support XRDS discovery.
> |
> | To use HTML-Based discovery, an HTML document MUST be available at the
> | URL of the Claimed Identifier. In the HEAD section of the document:
> 
> It seems that it has been unclear to some implementers what "HEAD
> section" means. This is not surprising as the correct term is "HEAD
> element" (HTML 4.01, section 3.2.1).

Agreed. This is just a simple language change.

> |A  tag MUST be included with attributes "rel" set to
> |"openid2.provider" and "href" set to an OP Endpoint URL
> |A  tag MAY be included with attributes "rel" set to
> |   "openid2.local_id" and "href" set to the end user's OP-Local
> |   Identifier
> 
> These should read "LINK element", not " tag".

While you're correct, I don't think it's that erroneous to say " 
tag" here. Still, it can't hurt to correct it.

> | The protocol version when HTML discovery is performed is "http://
> | specs.openid.net/auth/2.0/signon".
> |
> | The host of the HTML document MAY be different from the end user's
> | OP's host.
> |
> | The "openid2.provider" and "openid2.local_id" URLs MUST NOT include
> | entities other than "&", "<", ">", and """. Other
> | characters that would not be valid in the HTML document or that cannot
> | be represented in the document's character encoding MUST be escaped
> | using the percent-encoding (%xx) mechanism described in [RFC3986]
> | (Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic
> | Syntax," .).
> 
> This is incompatible with HTML parsing rules.
> 
[snip]
> 
> I think the whole section is flawed and should be replaced with a small
> note as a warning:
> 
>   Note: If the "openid2.provider" and "openid2.local_id" contain an
>   ampersand (&), this character MUST be escaped as "&" according to
>   HTML rules.

In practice, few implementations actually use an HTML parser to find 
these elements. These extra restrictions are present to facilitate 
regex-based parsing.

Since there is no regression if an implementation should choose to use a 
*real* HTML parser, I don't see the harm here. It's imposing extra 
restrictions only on people who want to use OpenID HTML discovery; the 
rest of the document uses the normal HTML rules, though there is one 
exception which I'll describe below.

> 
> BTW, good HTML parsers are mandatory to protect against HTML injection
> attacks. An ad-hoc parser might simply fall for something like that:
> 
>   
>   
>   Nice test
>   
>   Send me your comment:
>   
>   
>   
> 
> Yes, this is valid HT

Re: HTML parsing in HTML-based discovery

[Martin Atkins]

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  tag.
> - single quotes vs. double quotes vs. no quotes.
> - unescaped "<"/">" within attributes.*
> - numeric character references.*
> - line feeds within tags.*
> - additional XML namespaces that allow attributes like foo:href.*
> -  tags within .*
> - [to be continued]
> 
> (* = inspired by a real-world implementation failing to handle these 
> cases correctly)
> 

And, in theory, the OpenID spec could add additional restrictions to 
"fix" the above problems.

Whether it should or not is of course up for debate; I'd be interested 
to hear from Brad Fitzpatrick and JanRain's developers who are 
responsible for the most-used implementations currently using regex 
parsing. Why didn't you guys use an HTML parser? I assume there must 
have been a reason.

> 
>> This is mostly an ideological argument founded on whether we're allowed 
>> to impose additional restrictions on HTML documents that are making use 
>> of OpenID discovery. There is certainly no *practical* reason why this 
>> shouldn't be done, assuming that the restrictions are sufficient to 
>> prevent the above attack.
> 
> There are practical problems:
> 
> * Users can't use existing HTML tools to check for the additional
>restrictions. A validator will say "valid HTML" but the OpenID
>login fails due to a "parsing error" (e.g. the PHP implementation used
>on OpenID Enabled). And different RP will choke on different things.

An HTML validator also won't help them if they transpose the values of 
openid.server and openid.delegate, or if they type rel="opnid.server" 
instead. There are OpenID-specific "validation"/checking tools in the 
works which will hopefully be able to give users good information about 
potential pitfalls with the way they have written their HTML in addition 
to pointing out things like that the openid.server LINK is missing.

> * Users can't use existing HTML tools that do not honor the additional
>restrictions. A HTML pretty-printer may simply re-format the code in
>a way unparsable by ad-hoc parsers; a hypothetical htmlcrush program
>might may remove the optional quotes, entity references and tags in
>good faith.

Indeed. But those documents wouldn't conform to the OpenID 
specification. (assuming that it went into more detail about the 
restrictions it is adding to HTML.)


I think the main point here is that despite the outcome of this debate 
people *will* write regex-based parsers, whether the spec allows for it 
or not. We have a choice between ignoring the issue so that all of these 
regex-based parsers fail in interesting ways on odd cases, or accepting 
that this is inevitable and listing in detail a set of rules for 
regex-based parsing in addition to a set of restrictions on HTML that 
make those parsing rules possible.

I'd love it if everyone would use proper HTML or XML parsers, but that 
just isn't going to happen no matter how much we wish it would. In the 
end "almost there but not quite" implementations hurt no-one but the 
end-user, and OpenID is what will get the blame for any negative user 
experience, not the libraries that use incompatible regex-based parsers.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Martin Atkins]

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
> XmlHttpRequest will not do without extra security privileges.
> 

I think the spec is misusing the AJAX abbreviation a bit here, since the 
usual approach to doing this doesn't involve XMLHttpRequest at all, but 
instead works something like this:

  * Create hidden IFRAME in document and point it at OpenID RP endpoint 
on your site.

  * RP endpoint redirects (in the IFRAME) to the OP with 
mode=checkid_immediate, which instructs the OP to fail immediately if it 
needs to display any UI.

  * If OP needs to display an "are you sure?" page {

  * it redirects back to the RP endpoint (still in the IFRAME) and 
indicates that an immediate request was not possible.

  * the RP endpoint generates some HTML containing script that fires 
a callback in the containing page which causes it to do a normal 
redirect-dance OpenID request. This is often done in a new window to 
avoid disrupting whatever process started the OpenID auth request.

}
  * Else {

  * OP redirects back to the RP endpoint (still in the IFRAME) 
including the signature and all the other fun stuff you get on success.

  * the RP endpoint generates some HTML containing script that fires 
a callback in the containing page which does something like starting a 
session, putting the openid sig in the form to be validated later, or 
some other such action. (or maybe it just says "auth succeeded!" and the 
server validates it once the form is submitted.)

}

So no, this isn't really AJAX in the usual sense. As you noted, you 
can't do OpenID Auth client-side with XMLHttpRequest because of the 
same-origin restriction. You also can't do OpenID on the server because 
then the user's session cookie won't end up at the OP during the 
request. It still achieves the desired effect of doing an OpenID auth 
request without disturbing the current page, though.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OA2.0d11: Minor nit-pick regarding normalization

[Martin Atkins]

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://example4.com/ => http://example4.com/
 https://example5.com/ => https://example5.com/
 example6.com => http://example6.com

I believe that the last example should instead normalize to:
 http://example6.com/

* A HTTP URL without a path is a nonsense because the protocol doesn't 
allow for an empty path anyway. (You can't GET  HTTP/1.1)

* It's causes http://example6.com/ and example6.com to normalize to 
different strings, which is counter-intuitive.

* There is no useful reason to omit that slash except that the 
currently-specced normalization rules exclude it.


Therefore there should be an extra provision in section 7.2:

  * If the resulting identifier is an HTTP or HTTPS URL and it contains 
only the two slashes after the protocol specifier, an additional slash 
MUST be appended to the end of the string.

(not fussy on the exact wording.)


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal: An anti-phishing compromise

[Martin Atkins]

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 of not adding
> anything now.  I really like the idea that there be one thing in the
> core spec which reaches out to each extension.
> 

I propose:

openid.make_it_work=1


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Yadis/XRDS Service Element URI Question

[Martin Atkins]

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.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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, but I wonder 
why — if everyone owns their own DNS domain — we even need the user@ 
portion anymore? Largely that was included because in the early days — 
and even today, for many people — their addresses were 
[EMAIL PROTECTED]

My primary personal email address (not the one I use for mailing lists) 
is pretty redundant since the part before the @ is the same as the part 
after the @ once the parent domain has been excluded. Leaving off the 
user@ portion doesn't make the address any less "mine".

 > An 'email' address is simply the conventional conjunction of a
 > username portion and a DNS name portion. It need not be used only
 > for email, nor is it. It is routine for people to use RFC822
 > addresses for Jabber and other instant messaging applications.

Calling a Jabber ID an email address is a bit misleading. It's entirely 
possible for the email address [EMAIL PROTECTED] and the JID 
[EMAIL PROTECTED] to be owned/controlled by different people. It is not 
safe to assume that the two are the same person without evidence of 
that. What makes a string like "[EMAIL PROTECTED]" an email address is 
the fact that you can address email to it. The fact that the two 
addressing schemes use similar syntax doesn't help you much.







___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] OpenId & Yadis Question

[Martin Atkins]

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:
> 
> 
> http://specs.openid.net/auth/2.0/server
> https://sappenin.com/ 
> 
> 
> 
> Specifically:
> 
> A.) Is this the proper way to do delegation?  Above, gmail.com is delegating
> to sappenin.com.

What you've given above isn't delegation, because no delegate identifier 
is given. I guess you wanted https://sappenin.com/ to be your 
identifier, in which case it would go in the  element, with 
your provider's endpoint URL in .

Also, the Type here should be http://specs.openid.net/auth/2.0/signon.

You can also do it with LINK elements in an HTML document, as with 
OpenID 1 (though the "rel" values have changed a little).

> B.) If a client gets the Yadis doc above (after navigating to gmail.com),
> MUST they (or SHOULD they) navigate to sappenin.com and try to perform
> discovery again?  If so, how many delegates are allowed?  Not specified?
> 

Delegation isn't recursive. When given the above (corrected, of course), 
the site will try to verify https://sappenin.com/ against the given 
server immediately. Discovery is never performed on the LocalID in this 
case. This means that the nominated provider *must* be able to recognise 
the LocalID given.




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Modularizing Auth 2.0 Discovery

[Martin Atkins]

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

Currently the Authentication 2.0 specification has language in various 
places that constrains it to URIs with the schemes http, https and xri. 
For example, under "Terminology" the following definition is given for 
"Identifier":

 An Identifier is either a "http" or "https" URI, (commonly referred
 to as a "URL" within this document), or an XRI [XRI_Syntax_2.0].
 This document defines various kinds of Identifiers, designed for
 use in different contexts.

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 protocol". (or, indeed, 
words to that effect.) It would also nominate a standard XRDS service 
type URI to use during Yadis discovery.

Then we'd publish in parallel the following two ancillary specifications:
 * OpenID Discovery for HTTP and HTTPS URIs
 * OpenID Discovery for XRI URIs.

Later, the OpenID community or a third party could publish a 
specification "OpenID Discovery for Email Addresses", but I don't think 
we're really ready to go there right now.

The discovery protocols don't necessarily need to be XRDS-based, but if 
they are they would presumably reference the standard service type URI 
from the Auth spec so that future Auth versions can change this without 
needing to re-publish the discovery specs.

This has the following benefits:

   * It gives others a clear, spec-approved mechanism to bolt-on support 
for additional URI schemes.

   * It allows the Authentication specification to evolve separately 
from the various discovery specifications, which are unlikely to need to 
change very much from version-to-version.

   * It formalizes the separation between discovery and authentication, 
giving library authors a clear plug-in point if they wish to support 
modular discovery.

Presumably the OpenID Auth 2.0 spec would still retain a reference to 
the HTTP and HTTPS discovery spec purely so that it can say that RPs 
MUST support it regardless of what else they support.

-

All ancillary discovery specifications must, at minimum, define:

   * A pattern for recognizing and canonicalizing their own identifiers. 
(For example, the XRI one would include a provision for checking for an 
identifier which starts with a global context symbol, etc.)

   * A mechanism for returning the following information:
 - Either: (traditional identity case)
 * Canonical Claimed identifier (an i-number, for example)
 * User-supplied "Display" identifier (an i-name, for example)
 * OP endpoint URL
 * OP-local identifier (i.e. openid:Delegate as was)
 - Or: (directed identity case)
 * OP endpoint URL
 * Canonical OP identifier (for use in confirmation messages)

(And, of course, not all discovery mechanisms would necessarily support 
directed identity.)


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 starting point we should just refactor the existing 
XRI-related content from the Auth spec into a separate spec. We can then 
worry about simplifying it as a separate problem.

>> Later, the OpenID community or a third party could publish a
>> specification "OpenID Discovery for Email Addresses", but I don't think
>> we're really ready to go there right now.
> 
> Could you please elaborate on this? I believe the SMTP Extension is pretty
> solid. The only thing it lacks is formality.
> 

I'd rather not get into the debate about email-based identifiers here. 
This thread is about making it possible to have such a spec, not about 
which spec will be adopted and when. I encourage you to pursue this 
separately, assuming we actually do modularize the auth spec.


Cheers,
Martin
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 protocol". (or, indeed, 
>> words to that effect.) It would also nominate a standard XRDS service 
>> type URI to use during Yadis discovery.
> +1
> 
> can we also use the opportunity to put i-names support in an extension?

If this were to take the form I described in my original message, 
effectively *all* discovery mechanisms become extensions. The HTTP/HTTPS 
one gets special treatment by getting referenced by a MUST in the core 
spec, but it's still a separate document.

i-names would be handled as part of the "OpenID Discovery for XRI URIs" 
specification I mentioned.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 the relationship of
> the identifier being resolve to an XRDS document and the metadata needed to
> access other OpenID services.
> 

My revised proposal is that the Authentication specification would 
include, as part of a "Requirements for Discovery Protocols" section, a 
section on the use of an XRDS document as part of discovery.

The separate discovery specs would then describe identifier recognition 
and canonicalization, how to retrieve an XRDS document and any other 
special non-XRDS mechanisms as appropriate.

So the HTTP/HTTPS one, for example, would:

* Describe How to recognise and canonicalize its identifiers
* Require the use of Yadis discovery to obtain the XRDS document
* Refer to the relevant section of OpenID Authentication for the XRDS 
processing rules.
* Require that if Yadis fails RPs fall back on the non-XRDS-based HTML 
discovery, describing how this mode returns the necessary information.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 avoiding redundancy, I'd suggest the following 
distinction:
  1. XRI Resolution chapter 3 (or a separate spin-off spec) describes 
the syntax of an XRDS document.
  2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS 
URL.
  3. OpenID Authentication describes how to determine the endpoint URI 
and other information from an XRDS document, referencing [1].
  4. The new HTTP discovery specification would reference [2] and [3] to 
describe the XRDS-based HTTP discovery mode, and then go on to describe 
the HTML-based discovery fallback.

Alternatively, [3] above could be served by a separate spec "OpenID 
discovery using XRDS", though I think that may be overkill for something 
so straightforward.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 ridiculously big. The 
discovery rules in the current spec for just handling HTTP/HTTPS and XRI 
discovery are already big enough.

However, I clearly have a bias for lots of small specs over one large 
spec, and clearly your bias is the opposite. :)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 having to read about
> the full XRDS schema.
> 

Perhaps then Yadis (or something else) can describe the subset of the 
XRDS schema used for service discovery, referencing the full XRDS 
specification only as a formality?

I agree that XRI Resolution chapter 3 is a bit "big" for our purposes.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 documents people need to read in total.
> 

I like the idea of ditching the reference to Yadis spec and moving the 
parts about finding the XRDS document into my hypothetical "OpenID 
Discovery for HTTP/HTTPS URLs" specification and the parts about 
processing the XRDS document into the OpenID Auth spec.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 element to ancillary specs as before. These will define 
recognition/normalization rules for user input and how to take a 
matching URI and return an appropriate XRD element.

  3. Create "XRD discovery for HTTP URLs" which is really just the 
remaining stuff out of Yadis. *

 * HTML-based Discovery for OpenID remains a special case, but we 
can minimize the reach of this special case by stating in the HTTP URLs 
spec that if HTML-based discovery succeeds an implementation is to 
synthesize (or at least, act as if it synthesized) a 
functionally-equivalent XRD element containing Service elements for 
OpenID 1 and/or OpenID 2.

  4. Have OpenID Authentication 2 simply say “use XRD service discovery 
to find a service description for 
‘http://specs.openid.net/auth/2.0/server’ or 
‘http://specs.openid.net/auth/2.0/signon’” and then…” and go on to 
describe the interpretation of the URI element and the LocalID element.

It'd also contain a special provision that RPs MUST support 
HTTP-based discovery, to retain the baseline functionality from OpenID 1.1.

The minimal reading for an OpenID Auth RP implementor then becomes:
 * Core OpenID spec
 * XRD service discovery
 * XRD discovery for HTTP URLs

While the idea of having three required specs is a little scary, these 
three should be able to stand alone and the latter two will be quite 
simple since they are just formed by splitting Yadis in half.

"XRD discovery for XRIs" barely needs defining since XRI resolution 
already covers most of it. Just need to bring over the 
recognition/normalization rules from the Auth Draft 11 section 7.2.

-

This also maps nicely onto a potential set of libraries:

  * 1 glue library that takes as input a URI and a list of service types 
in order of preference and returns an XRDS Service element representing 
the best match.
 findService(URI, serviceTypes[])

  * n discovery libraries which have three operations:
 isMyIdentifier(string) - determine if this library "owns" this
 identifier.
 normalizeIdentifier(string) - return a normalized version of the
 identifier.
 findXRD(URI) - retrieve an XRD element for the given URI.

 These are called by the glue library and then the glue library 
parses the returned XRD element.

  * 1 OpenID library which does:
  service = discovery.findService("=mart", [
  "http://specs.openid.net/auth/2.0/server";,
  "http://specs.openid.net/auth/2.0/signon";,
  ])
  endpoint = service.getURI()
  localid = service.getLocalID() || "=mart"
  // etc, etc

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal for Modularizing Auth 2.0 Discovery

[Martin Atkins]

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 implementations MAY use those other
> methods of resolution ("native resolution", if you will). In essence, this
> is a requirement for HTTP gateway(s) to whatever resolution infrastructure
> exists today. 
> 

I don't really think it's necessary to *mandate* that a HTTP mapping 
always be used. After all, it's very easy for a spec to, if it's 
appropriate, define a mapping to an HTTP URL and then reference the 
HTTP-based discovery spec.

While I agree that at this point any discovery protocol that *doesn't* 
use HTTP is going to face an uphill struggle as far as real-world 
implementations go, if people want to go ahead and try to get their 
off-the-wall protocols adopted I don't see any reason why we shouldn't 
let them.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: HTTPS status

[Martin Atkins]

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 blogged about (
> http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID )
>  
> Can someone please tell me the status on this? Hopefully its being required!
> 

As far as I'm aware, the current status is:

  * All OpenID identifiers SHOULD use a secure channel.
  * All OpenID servers SHOULD use a secure channel.
  * OpenID relying parties MUST support SSL access to HTTP URLs.
  * OpenID relying parties MAY refuse to interface with identifiers and 
servers that do not use a secure channel.
  * All other connections are out of scope of OpenID Authentication.

I may be wrong on these, as I'm listing them from memory.



In practice, I expect all big OpenID providers will support SSL because 
users will demand it. The sites currently providing OpenID identifiers 
as value-add features alongside an existing service (LiveJournal, etc.) 
probably won't get used much once there are more "proper" providers.

People hosting their own identifiers and/or OPs probably won't use SSL, 
but then they won't be able to use their identifiers at any site which 
requires SSL-based OpenID Authentication, and they'll be in the minority 
anyway.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

XRD-based Service Discovery - Draft 1

[Martin Atkins]

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.


In particular:
 * XRI Resolution 2.0 is no longer required reading for implementors. 
Instead, it defines its own proper subset of XRDS/XRD which is 
completely defined within this document.
 * The various sentences referring to "authentication services" and 
specifically to OpenID, LID, etc. have been rewritten or removed.


My intention here is that the remaining parts of Yadis that are not 
included in this new specification will become "XRDS Discovery for HTTP 
and HTTPS URLs".


It'd be cool if it could be restructured in such a way that XRI 
Resolution 2.0 becomes only an informative rather than a normative 
reference, but as it currently stands it's used in conjunction with a 
couple of MUST clauses and therefore needs to be normative.


(I was going to put a more readable version of this on the wiki as well, 
but sadly it seems that OpenID login isn't working today... for me, at 
least.)























































































  
XRD-based Service Discovery - Draft 1

  
specs@openid.net
  




  
XRD-based Service Discovery describes the use of an XRDS document
to describe and discover services.
  

  

  

  
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .
  
  
  

  (AKA "End User" or "Subject".)  An entity
  using a URI as an identifier.


  A URI for which services can be discovered via this protocol.


  A computer software process (or system of processes) that provides one or more services located using this Protocol.


  A particular protocol or operation supported for a given URI, and the information needed to access it.


  An XML document using the XRDS format which describes services.


  A party responsible for a Relying Party Agent and on whose behalf that Agent acts. A Relying Party is relying on the services provided by a Resource.


  A role to be fulfilled by an agent that uses one or more services discovered as per this specification. The Relying Party Agent discovers the services available from an XRDS document, and may modify its own behavior accordingly.

  
  


  
The purpose of this specification is to define a method of discovering services
from an XRDS document. This specification uses a subset of the full XRDS schema,
which is fully defined below. Implementors may wish to refer to the full XRDS schema
in XRI Resolution, chapter 3 , though only
the subset described in this document is required for compliance with this specification.
  

  


  Extensible Resource Descriptor or XRD is a format defined by the XRI Technical Committee
  at OASIS. This specification uses only a subset of the full schema, defined in .



  

  


  Services are identified using a well-known service identifier URI. This URI is to be defined by
  the specification related to the service in question. Services can have associated with them
  additional metadata such as an endpoint URL at which the service can be used, and an identifier
  by which the service "knows" the current URI.



  The XRDS format allows the use of XML namespaces to extend the service elements with arbitrary
  additional metadata that is not provided for by the schema defined here.


  





  


  An XRDS document contains a Resource Descriptor, which provides a list of services.
  These are the services that are available for the URI used to
  obtain the XRDS document. In the case of some services, additional data is included in the
  Resource Descriptor for use by the Relying Party Agent in making a request to that service.
  Such additional data is not specified in this specification but is instead specified in the
  definition of that service.


The Resource Descriptor also enables preferences for certain services to be expressed through the priority mechanism.

  

  

Here is an example of a small XRDS document:



This document specifies two services.

Re: XRD-based Service Discovery - Draft 1

[Martin Atkins]

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 put a more readable version of this on the wiki as well, 
> but sadly it seems that OpenID login isn't working today... for me, at 
> least.)
> 

As it turned out, I had broken my identity URL. One of the perils of 
running your own!

Anyway, you can now see a wikified version of the draft spec here:
 <http://openid.net/wiki/index.php/XRD-based_Service_Discovery>

(It's created by my hacky XMLRFC-to-wiki Perl script, so there are some 
flaky bits... but hopefully it's good enough for now.)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Extensions key prefix

[Martin Atkins]

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 extension putting  
> data into those keys.
> 
> So, openid.ns.ax = http://openid.net/srv/ax/1.0 implies  
> openid.ax.required.
> 
> But it could just as easily be openid.ns.foo = http://openid.net/srv/ 
> ax/1.0
> in which case, your sreg values would be in keys named openid.foo.*
> 

I was aware of this previously, but now that you've spelled it out a 
thought has occured to me...

Most frameworks model the query string arguments as an associative 
array, so it's useful to know what key you're expecting ahead of time. 
With the above naming scheme, it seems to me that you'd have to search 
the entire query argument map for a key,value pair where the value is 
the URL you're looking for and the key matches /^openid.ns.(\w+)$/.

This seems sub-optimal, but I must admit I don't know what else to 
suggest. While putting the URL in the "key" and the prefix in the value 
would not be invalid, it'd be troublesome in PHP where for historical 
reasons it mangles anything that wouldn't be a valid variable name.

Or am I missing something?


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

HTTP Authentication Bindings for "two-party" OpenID Authentication

[Martin Atkins]

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 sense 
as a human does because they can fill the role of the OpenID Provider 
themselves.

A long time ago I posted a proposal where HTTP Authentication is used as 
a transport for this sort of two-party OpenID Authentication:

 

As noted on the wiki page, this is not intended to help non-human agents 
log into traditional RPs (e.g. websites) but rather to be used with 
specialized protocols where one non-human agent needs to talk directly 
to an RP without a user present.

The main problem people had with this at the time was the use of dumb 
mode, due to its vulnerability to MitM-type attacks. I would like a 
two-party authentication protocol like this for use in several 
machine-to-machine protocols I'm designing[1], but I'm reluctant to 
reference it right now while I know people (quite rightly!) have 
reservations about the security of it.

The obvious approach is to specify a way to do DH associations over an 
HTTP authentication protocol. However, it's not clear to me how to do a 
multi-stage authentication handshake efficiently over HTTP auth, since 
HTTP authentication is based around sending the request, getting back a 
401 Unauthorized response and then repeating the request in its entirety 
with appropriate authentication credentials.

I'm told that the Negotiate authentication scheme for Kerberos does this 
by retaining the request as state on the server and having the 
intermediate requests and responses contain no body, but this doesn't 
really seem in the spirit of HTTP.

I'd be interested in any insight that others may have to offer.


-

[1] My hope is that dependent protocols will be able to use 
interchangably either three-party request authentication via "OpenID 
Exchange"[2] or two-party authentication via this specification, so that 
protocols like "Send A Message"[3] will be able to work in both modes.

[2] http://openid.net/wiki/index.php/OpenID_Exchange_1.0

[3] http://openid.net/wiki/index.php/Send_A_Message_Protocol

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Promoting OpenID

[Martin Atkins]

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
http://openid.net/mailman/listinfo/specs

Re: SREG namespace URI rollback

[Martin Atkins]

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 solve the
> majority of problems today.
> 

Presumably once we're on OpenID 2, those that need extensions can just 
define their own extension namespace. They can follow the conventions of 
SREG if they want, though of course they can really do whatever they 
like as long as it can be represented in an OpenID 2 request.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Server-to-server channel

[Martin Atkins]

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 done for them. The RP 
> look up your account number in its database, and see X. And since the RP 
> has not received any updates to your bank account information, it 
> reasons that your account number is still X and consequently disburse 
> your payment on a stranger's account ...
> 

The "age" of the information needs to be taken into account here. If 
information is old, then the RP would presumably be hesitant to act on 
it without verification.

What constitutes "old" information depends on the attribute... things 
like "Full Name" are, for many people, changed never or at most once in 
their lives. However, things like a credit card number tend to change 
every few years as cards expire.

Some information has a built-in expiry date (such as credit card 
details), while other information just has a "likelyhood of change". 
This implies to me that the following three things are needed:

  * The possibility of a hard expiry date on a particular piece of 
information.
  * "soft" expiry dates which are more like "refresh this every n 
months", where the RP gets less and less convinced about the accuracy of 
the data as it ages, but may continue to use it for some time even when 
it's "a bit old".
  * The ability for an RP to request a refresh of attributes it stores 
without necessarily including the user in the transaction. (The user 
presumably will have made approval/revoking decisions out of band at an 
earlier time.)



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Server-to-server channel

[Martin Atkins]

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 come to me (my OP) and get it. Let me say "no". Let me know each
> time they ask. But most importantly, let me (my OP) provide the
> correct, updated info each time the RP wants it.
> 

I think you're kidding yourself if you believe that RP's won't cache the 
information they obtain.

For some things it's legitimate: they need to store your name because 
otherwise they'd need to talk to your OP (via you!) every time they 
render a page containing something attributed to you.

For other things it's more dubious than that, but the fact that it is 
technically possible means that at least some RP's will do it. I think 
it'd be a mistake to write the spec under the assumption that they won't 
unless we're going to include something that prevents it.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Server-to-server channel

[Martin Atkins]

[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 legitimate: they need to store your name because
 > MA> otherwise they'd need to talk to your OP (via you!) every time they
 > MA> render a page containing something attributed to you.
 >
 > OK - yes - I concede that some "data age" complexity does probably
 > creep back in if RPs choose to deny users the opportunity to audit the
 > use of user information.  (If I've got a choice between 2 RPs, and RP1
 > renders pages with my name in it, without giving me control over that,
 > while RP2 makes repeated calls to my OP every time it occurs: I'll
 > always choose to use RP2 - because it's the only one of the 2 options
 > that's "user centric", and gives me the ability to control the use of
 > my information.
 >
 > Yes - this could be a tough drain on RP and OP resources.  Tough.
 >

You can't just wash your hands of this problem because it doesn't suit 
your rather bizarre idea about how the world should be. Sites need to be 
able to attribute contributions to users, and in order to do that they 
need the user's name. A forum site cannot retrieve the name of every 
user that took part in a topic from their respective OPs while rendering 
  the topic page. "Tough" is not an acceptable answer: rendering a topic 
page is a legitimate function of a forum site and attributing each 
message is necessary.

 > MA> they need to store your name because
 > MA> otherwise they'd need to talk to your OP (via you!)
 > "via you!" is not a correct statement.  This is a "server-to-server"
 > topic: we're discussing a data flow that is "by your explicit prior
 > permission", but that takes place when you are not necessarily
 > present.

Right. Some people had been talking about not allowing this out-of-band 
information fetching. Even without the need for the user to be present, 
it's still prohibitively expensive.

 > MA> For other things it's more dubious than that, but the fact that it
 > MA> is technically possible means that at least some RP's will do it.
 > MA> I think it'd be a mistake to write the spec under the assumption
 > MA> that they won't unless we're going to include something that
 > MA> prevents it.
 > I do not follow your logic.  It looks like you're saying "there is an
 > opportunity for some RP's to act badly, therefore we should not even
 > try to code user-protection into the protocol"

On the contrary, I'm saying that if you don't want RPs to retain user 
information then you should include some TECHNICAL MEASURE that prevents 
them from doing so.

I think an acceptable compromise is to instead give users a way to 
express their wishes about how the data can be retained in the form of a 
"update this every n months/weeks/years/whatever" or a hard "expires on 
this date"-type rule. This way you acknowledge that there are indeed 
applications that need to retain user information for certain purposes 
and allow the user to have some control over this process. You could 
also put in a "don't retain this at all" flag, which in my forum case 
would probably cause the forum to just identify you by your raw OpenID 
identifier and have done with it.

 > By all means - include preventative code (and for some kinds of
 > attributes, digital time-stamped and signed assersions about the
 > attributes solve these problems).  But I think it's a far bigger
 > mistake to completely leave out a server-to-server channel altogether.

I have nothing against the server-to-server channel. In fact, the 
server-to-server channel is a prerequisite for the "update this every n 
months" thing because otherwise the RP would have no way to do that update.

 > When a rogue RP violates your trust and caches data without your
 > permission, that's bad.

So a way is is needed for:

  * A trustworthy RP to indicate how long it would like to retain 
certain items of data
  * A user to indicate how long he would like certain items of data 
retained for, or how often the RP should try to refresh that data.
  * A way for the user to prevent further updates of a particular 
attribute by a particular RP after a certain date.

The first and second points above would, I think, be helped by defining 
some reasonable defaults for each attribute type, just so that the 
average user doesn't necessarily have to spend ages entering update 
frequencies and expiry dates every time some attributes are requested 
for the first time.



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Server-to-server channel

[Martin Atkins]

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 clear that I'm not pushing for 100% of data to
> "live" at the OP: rather - I want to give the user a choice in the
> matter (that is - after all - the entire spirit of "user-centric"). I
> want users to have the *option* to decide whether to "sign up" to RP#A
> or RP#B, and be able to base their decision upon the data-handling and
> protection practices of the RP.  Some RP's will want to store
> everything just like they do today.  Some will want to embrace user
> centricity and give their customers full control, and most will
> probably tread a line somewhere inbetween.
> 
> As long as we build something that supports all this, then we can
> leave it up to the normal market forces to steer the "Identity future"
> the way they want - with the key issue (for us) being that OpenID has
> the chance to persist in this future.  Right now - OpenID is right at
> the bottom of the pile, being almost the worst "Identity 2.0" protocol
> currently on the market.  IMHO - this is a problem that's easily
> fixed.
> 

I believe we are aiming for much the same thing, though perhaps I'm 
coming at it from a different perspective. My original message was 
proposing support for expressing the user's desires for how long 
particular data items should be retained without refreshing them, which 
seems to fit into your world view as described above.

I was simply suggesting that expecting RPs to retain *no information at 
all* is unrealistic, and so we should provide a mechanism for users to 
express how they would like their data to be used rather than just 
assuming that RPs will retain nothing.

> I wrote:
>>> Yes - this could be a tough drain on RP and OP resources.  Tough.
> You wrote:
> MA> You can't just wash your hands of this problem because it doesn't suit
> MA> your rather bizarre idea about how the world should be. Sites need to be
> 
> I contest that I *am* allowed to "wash my hands" at this point,
> because it is absolutely my problem: I operate an OP, and I'm involved
> in helping RPs accomplish "Web 2.0" goals.  I'm smack in the middle of
> all the consequences that flow from allowing users to control their
> own data howsoever they wish. 
> 
> I further contest that the idea of me being in control of my own
> information about me is not bizarre.  It might not be how anything on
> the web works today - true - but I'm pretty confident this is
> something most people do, or will, want.
> 
> Imagine you're at the newsagent buying a magazine.  You hand over
> your credit card, and the shopkeeper says "No problem - I'm happy to
> sell you your goods, but I need you to first agree to let me make a
> photocopy of your credit card, grab you name and email address, and 
> keep it in all on our files for the next 10 years.  Oh - and we'll
> need to be sending you the occasional marketing message from time to
> time over those 10 years as well."
> 
> Now *that* is something that almost everyone will agree is bizarre.
> 

Note that I was focusing on the example you gave of a user's name, 
rather than of a user's credit card information. Different data deserves 
different treatment. I'll wholeheartedly agree that it's undesirable for 
a vendor to retain credit card information — they currently do so 
largely because there's nowhere else that it can be centrally stored and 
retrieved, but AX changes that — but other data such as a user's name 
are another matter.

When I meet people, I routinely tell them my name. I don't expect them 
to immediately forget my name after our conversation — in fact, like 
most people, I'm probably subconsciously offended when people *don't* 
remember my name. I control people's access to that data by simply not 
telling them in the first place.

I think that what we can take from this misunderstanding is that not 
only do different *attributes* have different usage expectations, but 
also different *situations* have different usage expectations: you're 
largely focusing on businesses and financial transactions, while I'm 
largely focusing on social situations such as forums, weblogs and social 
networking. This may be caused by a difference in our backgrounds or 
interests, but whatever the reason it does show that different 
situations call for different behavior, and is yet another reason why 
users should be able to express their desires on a case-by-case basis if 
it is important for them to do so. I like Vinay's subsequent suggestion 
that this somehow be made legally binding, although I'm not sufficiently 
knowledgable about the relevant law to know how that can be put into 
practice.


[snip]
___
specs mailing list
specs@openid.net
http://openi

Re: Web Access Management

[Martin Atkins]

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 non-existent
> on the mailing lists.  Any insights?
> 

It seems that at this time the uncertain policies for issues such as 
patents and trademarks surrounding OpenID are putting off larger 
companies from directly participating.

This is a current hot-topic for the OpenID Foundation, since getting 
such companies fully on board would likely be beneficial.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Web Access Management

[Martin Atkins]

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.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 common enough term that 
confusion is unlikely by any knowledgeable developer, I suggest that if 
it be changed it be changed to "name-value form encoding", since I think 
this is more commonly used than "keyword-value".


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 who like rugby may be thinking and acting the  
> same way, or
> - most of my friends would go if they knew rugby, but they haven't  
> discovered it yet.
> 

 From a purely selfish point of view, I'm happy for this discussion to 
take part on the specs list just so I don't have to join and configure 
YET ANOTHER MAILING LIST(tm).

:)

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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 it's a good idea to modularize specifications in the 
same way as you'd probably modularize the implementation. This is why[1] 
I was pushing for separate Auth / service discovery stuff: the service 
discovery stuff is obviously useful for things other than auth, and 
there are *already* separate libraries for it (Service::Yadis and 
friends), so it makes sense for it to be given as a separate specification.

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, but my gut feeling is that it'd be a 
good idea for someone to make an experimental implementation to get some 
implementation experience and then it'll probably be a lot more clear 
where the articulation points are that make spec modularization 
worthwhile. There's little point in debating it at this early stage, in 
my opinion.

-

[1] One of the reasons, anyway. The other reason was to reach a 
situation where the OpenID Authentication specification can largely 
reference only other specifications under the OpenID umberella, which 
means bringing the "Yadis" tech into OpenID land (which it basically 
already is, despite the distinct brand) and defining a subset of the 
XRDS schema to avoid referencing the entirety of XRI Resolution 2.0, 
which contains lots of stuff that is not necessary for OpenID and 
related tech.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Authentication Protocols for Non-browser Apps

[Martin Atkins]

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 the different transport.

 

That protocol alone allows a non-human agent to authenticate as itself 
when acting as its own OP. This means that it is able to maintain its 
own associations and can compute its own assertion signatures.

I've drafted a second protocol that would allow the above protocol to be 
used for human users that use a traditional OP:

 

This does unfortunately require special support from the OP. Given that 
support for this protocol or another protocol like it is very important 
for non-browser app authentication I'm wondering if perhaps it should be 
rolled into the core OpenID Authentication 2.0 spec; as it currently 
stands, it's really just a different interface to what the OP already 
does, so it wouldn't be a massive extra implementation burden, though 
there are some remaining issues I've outlined in that wiki page that 
will certainly need to be addressed first.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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
> openid.net to offer something - even just as a 'getting started point'.
> 
[snip]
> 
> What we need now (from my point of view) is a base set that we can work
> against to build momentum behind AX (building on the momentum already
> behind OpenID).
> 

If our goal is to not reinvent the wheel, then let's just identify some 
AX mappings for the existing SREG fields, thus killing two birds with 
one stone: people migrating from SREG get some fields that offer 
one-to-one mappings, and these fields can be defined just by referencing 
the existing SREG specification so we avoid having to define anything.

SREG seems to be working well in the common case, so it seems like a 
reasonable place to start.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Authentication Protocols for Non-browser Apps

[Martin Atkins]

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 completely unrelated to my use case, or it
> could be squarely in the same place. 
>   In your proposal, is there any interaction with a user? If so, when?
> All I see is that the "caller" sends a signature with the authenticated
> request. Is this implying that the "caller" performs some function with the
> OP to generate this signature? How does this happen? Can I use an existing
> OP with my URL or XRI to generate this signature? If so, how? 
> 

The HTTP authentication bit does not specify how the signature is 
obtained. This is because when some application service is 
authenticating as itself it can maintain its own associations and 
generate its own signature without the indirection.

Where the Signature Request Protocol comes in is making this protocol 
applicable to user authentication as well. Unfortunately, it *does* 
require the OP to support an additional protocol mode where the user is 
authenticated using HTTP authentication (or some other 
machine-interpretable authentication) rather than HTML forms and 
redirections.

The flow I'm expecting for the latter is, to take the Last.fm client[1] 
as an example, that the user will enter an identifier URI into the 
preferences dialog where currently a username/password is entered. When 
the client-side app needs to make a request, it'll first do an 
unauthenticated request and see what HTTP authentication mechanisms are 
supported, and then prompt the user for appropriate credentials.

In the future, I'm hoping that the signature-fetching steps will be 
replaced with "call into an installed system service which will prompt 
the user to release a signature", thus avoiding the need for the user to 
give up the credentials to the client app and allowing the user to 
approve each application is is often done with a desktop firewall.

[1] http://www.last.fm/tools/downloads/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Auth 2.0 Extensions: Namespace Prefixes

[Martin Atkins]

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

It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:
 openid.extensions=blah,sreg,ax

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the "key" part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.




[1] I'm looking at you, PHP.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Specifying identifier recycling

[Martin Atkins]

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 when the 
> account was created, if the OP is amenable.
> 

If you're going to use i-numbers, then there's no reason at all not to 
use the XRD CanonicalID element. The same mechanism that's used to map 
i-names onto i-numbers can also be used to map URLs onto i-numbers, or 
URLs onto other URLs.

I'm sure Drummond can talk in more detail about this. We did discuss it 
briefly at IIW, but once the majority had decided that the fragment 
approach was the way to go we didn't get a chance to investigate this 
further.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs