Subject: [dix] DIX use cases

From: Robert Yates <[email-masked]>
Date: Tue, 21 Mar 2006 15:12:37 -0500

So from what I could make out DIX requires a set of use cases and a 
concrete reason why SAML et al doesn't cut it.  I thought I'd give it a 
go while this is all fresh in my mind.

Use Cases

1. Elliot's dad wants one userid and password for the web.
2. Elliot's dad wants to stop retyping his credit card information and 
shipping address every time he wants to buy something on the web
3. Elliot's dad wants to share his online pictures with me and elliot 
(and only me and elliot)
4. I want to subscribe to Elliot's dad's photocast so that as new photos 
become available they are automatically downloaded to my machine. 
http://www.apple.com/ilife/iphoto/features/photocasting.html
5. I want to print Elliot's dad's photos using a web photo printing 
website.  The web site that I use to print the photos is different to 
the one that stores the photos.

Observations

1&2 are accommodated by dmd1 and SAML, Liberty Alliance et al. SAML 
however requires some previous relationship between homesite and 
membersite (is this true?  do they need a common CA?)
3. is almost covered by dmd1 and SAML but I still don't understand how I 
either get the persona-url from an e-mail or an e-mail from a persona-url.
4 is not presently covered by dmd1 or SAML (AFAIK).  I honestly believe 
that authentication via feedreaders and other "rich clients" are a MUST 
have requirement.  If the blogosphere forms part of the justification 
for DIX then not allowing bloggers to make blog postings using a rich 
client over atompub 
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt 
seems wrong.  Phillip's suggestion around federated digest seems to make 
a lot of sense.  If use case 4 makes it into the list of requirements 
for DIX then this would seem to be a significant differentiator between 
it and SAML.  DIX can do REST, SAML can only do Web Services and we all 
know how popular those are at the moment 
http://www.loudthinking.com/arc/000575.html.
5. can be accomplished by SAML.  This use case would probably not be in 
core DIX, but it should be possible to build atop the DIX foundation

Rob

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Mar 2006 14:29:35 -0600

> 1. Elliot's dad wants one userid and password for the web.

But in practice not every service will join the same federation, so I
suspect that for market reasons we can do no better than a small number
of identities and credentials, each for a set of many services.

> shipping address every time he wants to buy something on the web

Note that Elliot's dad almost certainly has multiple credit cards and
will sometimes want to use one and sometimes another, and there won't be
a pattern the browser/whatever can discern (e.g., "this card's balance
got too high and I'll carry some over, so let's make charges on this
other card for a while").

In other words: the identity selection problem simply won't go away, and
at the limit always requires human interaction.

> http://www.apple.com/ilife/iphoto/features/photocasting.html

By "automatically downloaded" in (4) I assume you also mean "when I'm
not around," by which you would probably mean that you want some form of
authentication mechanism/credential that doesn't require human
interaction to use.

Have I guessed correctly?

> either get the persona-url from an e-mail or an e-mail from a persona-url.

Presumably you'd be signing these e-mails somehow, no?  S/MIME, or PGP?

:)

> http://www.loudthinking.com/arc/000575.html.

I don't see why SAML can't handle (4), assuming I guess correctly what
you meant by (4), since SAML doesn't handle authentication mechanisms
directly, so that as long as you can authenticate to your IdP with some
mechanism/credential that requires no interaction then SAML should not
require interaction either.

Nico
--

---

From: Robert Yates <[email-masked]>
Date: Tue, 21 Mar 2006 16:09:56 -0500

>of identities and credentials, each for a set of many services.
What federation?  There is no federation in DIX.  This is one of the 
reasons it is really important.

>>at the limit always requires human interaction.
Agreed, but these are details that are beyond the protocol and that are 
handled by the implementation of homesites.

>Have I guessed correctly?
yes, 4 is actually an attempt to make two points, one is that I am not 
around, the other is that my "feedreader" is an http "rich client" i.e. 
it is NOT a browser.

>Presumably you'd be signing these e-mails somehow, no?  S/MIME, or PGP?
Sorry, I should clarify, added the word "address" to my statement below.

I still don't understand how I either get the persona-url from an e-mail address or an e-mail address from a persona-url.

>require interaction either.
There is a SOAP binding for SAML, but AFAIK no binding to straight http 
i.e. REST web services.  It is not possible, for example to use SAML 
with feedreaders. So apple's iPhoto could not use SAML if it continues 
to use feeds for Photocasting.

Rob

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Mar 2006 17:16:05 -0600

> around, the other is that my "feedreader" is an http "rich client" i.e. 

The second point to me translates as "forms&cookies is no good for
authentication" and follows from the need, generally, for human
interaction to properly fill in forms.

> Sorry, I should clarify, added the word "address" to my statement below.

I repeat my comment :)

> I still don't understand how I either get the persona-url from an e-mail 
> address or an e-mail address from a persona-url.

I haven't gotten that far with understanding the DIX materials, but I'd
like to restate your point (3) as: users (and apps) need to be able to
create access controls that refer to the identities (or attributes
thereof) that they 'meet'.

In your example the problem is that the 'meeting' happens in a context
(e-mail) apart from the world where DIX is applicable.

Is this restatement correct?

> to use feeds for Photocasting.

Hmmm, I'm not sure this is right, but what is right is that the way to
use SAML in HTTP is not as easily abstracted from the application as an
authentication layer in the HTTP protocol would, and I'm not sure that
DIX is any different from SAML in this sense.

Nico
--

---

From: Jeff Hodges <[email-masked]>
Date: Tue, 21 Mar 2006 16:46:04 -0800

Robert Yates wrote:
 >  SAML can only do Web Services

Incorrect -- and where did that notion come from?

The web browser SSO profile of SAML [1], employing either the SAML HTTP 
Redirect Binding or the HTTP POST Binding [2], are essentially RESTful, AFAIU.

JeffH

[1] SAMLv2 Profiles
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

[2] SAMLv2 Bindings
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

---

From: Robert Yates <[email-masked]>
Date: Tue, 21 Mar 2006 22:10:44 -0500

Jeff Hodges wrote:

> The web browser SSO profile of SAML [1], employing either the SAML 
> HTTP Redirect Binding or the HTTP POST Binding [2], are essentially 
> RESTful, AFAIU.

agreed, but i think you may be quoting me out of context :).  What I'm 
trying to state is that SAML cannot be used with non-browser REST based 
web services such as the atom publishing protocol.

Rob

---

From: Peter Davis <[email-masked]>
Date: Tue, 21 Mar 2006 22:38:48 -0500

> web services such as the atom publishing protocol.

As near as I can discern from atom-pub [1], it is, at it's heart, webDAV for
ATOM-based representations. Which means a feed reader/editor is, by
definition, an HTTP(s) user agent.

The present atom-pub ID is ambiguous for UA support for 3xx class response
codes (which would be required for the HTTP redirect binding).  The POST
binding carries no such dependencies on HTTP 3xx responses however.

SAML POST only requires access to the POST and GET verbs of HTTP, and for
convenience, support for response codes 3xx (redirect response codes), but
those are not MTI for SAML POST to properly function.

The defense RESTs ;-)

=peterd  (http://xri.net/=peterd)

[1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt

---

From: Peter Davis <[email-masked]>
Date: Tue, 21 Mar 2006 23:02:51 -0500

> reasons it is really important.

FWIW, I'd avoid the term 'federation', as I think its definition differs in
various communities.  My personal interpretation, for example, involves
parties agreeing (perhaps contractually) to the exchange of identity claims
(note that here, identity may or may not equal principal), and recourse for
false (or at least misleading) claims.

dmd1 provides some groundwork for blindly requesting and responding to
identity claims, where either or both of the parties involved may not ever
have interacted in the past.  This falls outside my personal definition of
federation, but perhaps not others definitions.

The value of these blind attestations, on the other hand, carry the burden
of questionable reliability. In (my definition of) 'federations', this is
mitigated by governing agreements and policies, which tend to underpin so
called 'federations', in some attempt to ensure proper behavior of the
parties involved. Blind attestations, in order to be believable, need
measures of confidence applied (which may be as simple as the context of a
deployment).

Different deployments will require different levels of assurance, but should
not rely on different protocols to request/respond with claims.

---

From: Robert Yates <[email-masked]>
Date: Wed, 22 Mar 2006 08:52:23 -0500

>definition, an HTTP(s) user agent.
Agreed.

>those are not MTI for SAML POST to properly function.
Not so fast ;-)  The SAML POST binding requires that the HTTP UA be a 
browser or at the very least it MUST be capable of rendering HTML forms 
and then making posts of media type 
`application/x-www-form-urlencoded'.  There is no such requirement on 
atom clients, nor any HTTP UA. Google, for example, has an ATOM client 
that is a plugin for word http://buzz.blogger.com/bloggerforword.html.  
This certainly can't presently make use of SAML's POST binding.  While 
it can be argued that these clients could make use of this binding I 
think the burden of being capable of parsing HTML Forms, forming a post 
of media type 'application/x-www-form-urlencoded' and dealing with all 
the character encoding pitfalls of html is too great when all they are 
trying to do is authenticate.

The SAML redirect binding has more potential, as all HTTP UAs should 
honor the 3xx return codes. The problem with this binding, that is also 
shared with the POST binding, is how the user indicates to the SP the 
location of his IdP.  One approach is that the url that the client 
initially hits (e.g. the feed url) contains the users IdP, so that the 
SP knows where to send the redirect (in use case 4, the user is not 
around). Embedding state into the urls of web resources is NOT REST 
based web services as it breaks one of the foundational assumptions. 
(this is getting religious).  Practically speaking though, doing so 
creates a set of problems for Elliot's Dad, Elliot and I.  Here's the 
problem.

Elliot's dad's photostream has the following url.  
http://apple.com/photostreams/elliots-dad. He e-mails the url of this 
feed to Elliot and I.  Now what?

Am not sure you can REST just yet.  Your witness ;-)

Rob

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Mar 2006 13:21:59 -0600

Robert,
> 1. Elliot's dad wants one userid and password for the web.
Three clarifications:

    * My father doesn't mind multiple user names so long as those can be
      stored somewhere.
    * My father doesn't mind different systems having multiple passwords
      so long as he doesn't have to remember them.
    * It's "Eliot" ;-)

There are other constraints to "Eliot's Dad" problem, but I'll go
through those in another message.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Mar 2006 13:33:59 -0600

> through those in another message.

But your dad probably does mind the endless enrolments, and thinking up
usernames and passwords that must be good, memorable for a few minutes,
different from the others he already has and which he will never type in
again.  And he probably minds not being able to use any of these
username/password tuples that he doesn't remember when he's using a
computer other than his primary one.  And he'd probably like to be able
to use Internet kiosks (e.g., when travelling w/o a laptop) w/o
endangering his credentials and associated resources.  And he probably
wants to be able to keep these username/password tuples when he
re-installs his system(s) (which he probably also minds doing, but at
least that's not a problem we'll concern ourselves with here).

I think Robert meant that your dad wants to have to remember no more
than one username and password, not that there mustn't be others under
the covers.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Mar 2006 13:49:03 -0600

> than one username and password, not that there mustn't be others under

This is the high order bit for him.  Endless registration is also an
issue, and these are two different problems.

Eliot

---

From: Jeff Hodges <[email-masked]>
Date: Wed, 22 Mar 2006 12:17:33 -0800

Robert Yates wrote:
 >
 > What I'm trying to state is that SAML cannot be used with non-browser REST
 > based web services such as the atom publishing protocol.

Not correct, in a literal sense. Abstractly, it's sorta correct in that the 
presently-specified set of SAMLv2 profiles may not address your particular needs.

However, somewhat subtle, and very important aspect of SAML is that: "If there 
is not yet a SAML Profile that does what one needs, then one can craft a new 
profile to accomplish it."

The -sip-saml-05 I-D [1] is an example of just such an exercise.

JeffH

[1] SIP SAML Profile and Binding
http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Mar 2006 14:47:26 -0600

> issue, and these are two different problems.

Yes, but the endless enrolment problem hadn't been explicitly stated.

I've been trying to distill, out of rather broad problem descriptions,
concrete real-world problems.  Very general descriptions of the problem
may help us to not solve specific problems in ways that aren't so useful
(replacing one problem with an equally bad, but different problem), but
I don't want to keep guessing what the specific problems are either, and
I do believe we need to know what specific problems we want to solve.

We also need to establish what threat models apply in what
circumstances.  This is critical, IMO.

If the IETF is going to do any work in this space then an overly broad
charter, either in problem description or solution space, is likely to
lead to failure.  'Twould be better to debate such matters now than two
years into a WG's life.  Chartering a WG should not be the only measure
of success here (see Phillip's post on that topic).  Cynics might also
prefer that any such WG be limited to their preferred solutions to their
perceived problems; an overly broad charter does not achieve that.
Everyone else should still want a narrow charter to improve the chances
of success.

So, is it safe to say that some of the use cases posted by Robert amount
to saying that

 - users shouldn't have more than one physical
   (smartcard/token/whatever) or logical (username/password) credential

 - non-interactive authentication/ID exchange/whatever must be supported

 - no more endless enrolment by creation of username/passwords

 - it should be easy to manage authorization

 - etc...

?

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Mar 2006 14:51:10 -0600

On Wed, Mar 22, 2006 at 12:17:33PM -0800, Jeff Hodges wrote:
> However, somewhat subtle, and very important aspect of SAML is that: "If 
> there is not yet a SAML Profile that does what one needs, then one can 
> craft a new profile to accomplish it."

And with less effort than starting from scratch.

---

From: Peter Davis <[email-masked]>
Date: Wed, 22 Mar 2006 22:28:02 -0500

On 3/22/2006 8:52 AM, "Robert Yates" <[email-masked]> wrote:

> `application/x-www-form-urlencoded'.

Fair enough.  (tho any self respecting webDav client should, which is what
various blogging tools really are)

>  There is no such requirement on

You are correct.  As others have pointed out, however, conveying these
messages as text/xml rather than application/x-www-form-urlencoded is not
out of the question.
> location of his IdP.

This (I think) is a challenge for any protocol proposal.  IDP discovery has
always been a challenge (esp when the user uses several IDPs for various
purposes). Even with dmd1, we are faced with a requirement to have the user
submit a URI to the SP to determine the IDP.

>  Here's the 

Again, assuming for the moment that you and Eliot use different IDPs, you
would have to provide apple with some 'hint' as to where to try to route an
authentication/attribute request.  We have to go under the assumption that
many IDPs will exist, and we'll need one (or more) mechanisms to:

A] provide the relying party with at least a hint as to the set of IDPs the
user and RP are willing to use for a given transaction/

B] convert that hint into something richer (metadata), which arms the RP
with both the capabilities and endpoints in order to conduct the
authentication

> Am not sure you can REST just yet.  Your witness ;-)

Hehe. RESTful puns could get pretty bad. I'll give it a REST.

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Mar 2006 07:55:47 -0600

> various blogging tools really are)

I can't vouch for them being "self-respecting" but here are some  
WebDAV clients that do not render HTML at all, so can't use HTML  
forms to authenticate:
	 - Mac OS/ X "WebDAV-FS" tool in the OS, which mounts a remote  
WebDAV repository as a file system (very NFS-like)
	- Windows NT and XP and later, "Network Places" or File system  
"Redirector" which do the same
	- Xythos WebFile Client, mounts WebDAV repository as a Windows drive
	- cadaver, command-line WebDAV client for *nix
	- sitecopy, *nix utility for synchronizing local and remote file  
system content over WebDAV
	- Chandler, general sharing and calendar sharing client (CalDAV)
	- Mozilla "Sunbird", calendar client
	- Evolution calendar client
	- MS Outlook Express, email over WebDAV
	- SVN clients, doing source gets/puts/synchs over WebDAV
	- Adobe Acrobat, GoLive, Photoshop and others, share "workgroup"  
documents on WebDAV

There are more listed at <http://www.webdav.org/projects/> though  
it's not complete either.

Lisa

---

From: Peter Davis <[email-masked]>
Date: Thu, 23 Mar 2006 12:48:26 -0500

> WebDAV clients that do not render HTML at all, so can't use HTML

I think this thread has (at least for me) is teasing out a new requirement .
It underscores the need to ensure support for non-HTML aware HTTP clients.
While many of the DAV clients Lisa enumerated use shared HTTP engines, they
may not always avail themselves of shared HTML engines.

As a result, perhaps a new requirement may look like:

- the protocol shall support the transfer/transport of security tokens over
HTTP, but does not require implementations to support the HTML form controls
<form> and the associated encodings (eg: Calendar Clients, FS-browsers,
etc...)

Maybe that requirement (or a close cousin) is already there.  I cannot seem
to drudge up the present requirements thread...

---

From: Robert Yates <[email-masked]>
Date: Thu, 23 Mar 2006 12:57:03 -0500

><form> and the associated encodings (eg: Calendar Clients, FS-browsers,
+1

>to drudge up the present requirements thread...
In an earlier thread Dick had ruled out of scope what he refers to as 
"Rich Client" applications.  At the BOF they were on the in/out list. I 
believe that they need to be firmly on the "in" list.

Rob

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 24 Mar 2006 01:04:10 -0600 (CST)

On Thu, 23 Mar 2006, Peter Davis wrote:

> I think this thread has (at least for me) is teasing out a new 
> requirement. It underscores the need to ensure support for non-HTML 
> aware HTTP clients. While many of the DAV clients Lisa enumerated use 
> shared HTTP engines, they may not always avail themselves of shared HTML 
> engines.
>
> - the protocol shall support the transfer/transport of security tokens 
> over HTTP, but does not require implementations to support the HTML form 
> controls <form> and the associated encodings (eg: Calendar Clients, 
> FS-browsers, etc...)

There are dozens of deployed web signon schemes using a third-party 
authentication service (eg SXIP, the SAML browser profiles, OpenID, etc), 
and to my knowledge all of them make use of all the browser features 
(redirection, cookies, form-based username/password entry) that make them 
not applicable to non-browser HTTP user agents.  Organizations base their 
authentication strategies around these schemes, all of them aware that 
these schemes are web-browser-only.  They do this because, guess what, the 
apps of interest are also web-browser-only apps, and those apps are 
web-browser-only because they also want to work well with browsers so they 
use all those browser-only features.  We all use these apps constantly.

So it certainly would be a good thing to have an authentication system for 
all HTTP purposes with all the wonderful properties we're seeking 
(internet scale, ease of deployment, identity-info exchange, etc).  This 
is true in the same sense that it would great to have such a system for 
IMAP, SMTP, LDAP, CIFS, NFS, etc etc.  For my organization and my 
community, I think good HTTP authentication is about as important as good 
authentication in all those other app protocols.  And none of them is 
nearly as important as web authentication (ie, authentication of browsers 
to web-browser-oriented apps).

(See

   http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

for discussion of improving HTTP authentication, btw.)

My point is that, odd as it may seem, web authentication, as deployed in 
zillions of instances today, has almost nothing to do with HTTP 
authentication.  Insisting that a single scheme support them both, or a 
single Working Group effort make both work equally well, is adding a 
pretty serious amount of additional work and constraint on the solution.

Maybe the emerging importance of RSS and AJAX and WebDAV and Caldav and 
their use in web-app scenarios changes the balance and makes us want to 
tie web authentication and HTTP authentication together more than we used 
to.  Could be.  But I think there is much good work to be done on 
developing and deploying really good web-app-only schemes while we also 
work on that grand convergence.

  - RL "Bob"

---

From: Johannes Ernst <[email-masked]>
Date: Fri, 24 Mar 2006 08:45:12 -0800

On Mar 23, 2006, at 23:04, RL 'Bob' Morgan wrote:
> authentication service (eg SXIP, the SAML browser profiles, OpenID,  
> etc), and to my knowledge all of them make use of all the browser  
> features (redirection, cookies, form-based username/password entry)  
> that make them not applicable to non-browser HTTP user agents.

FYI: Yadis and LID were explicitly designed to be usable by software  
that doesn't have a GUI, and OpenID can be used that way as well.

E.g. Yadis finds its capability file either through requesting a  
special mime type, or an additional HTTP header, and only if those  
fail, looks into HTML (if there is, in order to support those folks  
who cannot really get at the configuration of their http server).

LID takes a URL, and signs it with a GPG key pair; this requires  
neither HTML nor a GUI.

So it can definitely be done, and it's all deployed and working as  
you know.

Johannes Ernst
NetMesh Inc.

  http://netmesh.info/jernst

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 24 Mar 2006 14:08:15 -0600 (CST)

> that doesn't have a GUI, and OpenID can be used that way as well.

That's a nice feature for a system to have, but it's not the same as the 
point I was making.  There's more to the obstacles than just GUI.

Can YADIS/LID/OpenID be used to authenticate a WebDAV client to a WebDAV 
server, for some/most/all of the current typical WebDAV clients and 
servers?  If so, then you've met the requirement Peter set.

  - RL "Bob"

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 24 Mar 2006 14:26:45 -0600 (CST)

On Fri, 24 Mar 2006, Johannes Ernst wrote:

> FYI: Yadis and LID were explicitly designed to be usable by software that 
> doesn't have a GUI, and OpenID can be used that way as well.
>
> E.g. Yadis finds its capability file either through requesting a special 
> mime type, or an additional HTTP header, and only if those fail, looks 
> into HTML (if there is, in order to support those folks who cannot 
> really get at the configuration of their http server).
>
> LID takes a URL, and signs it with a GPG key pair; this requires neither 
> HTML nor a GUI.
>
> So it can definitely be done, and it's all deployed and working as you know.

And, forgive my ignorance, aren't OpenID and LID agnostic about the actual 
means of authentication performed between the authentication service and 
the user agent?  So if someone deploys it using form-based authentication, 
or taking advantage of some existing form-based authentication, then that 
would require UI, and would make the system fail to work for non-UI user 
agents, would it not?  You can say:  well, then don't deploy it that way, 
use Basic or something; but telling people not to use stuff they like to 
use isn't a winning strategy usually.

It could be useful to look at standard ways to accomodate GUI and non-GUI 
user agents each with appropriate methods with the same installations.  Or 
perhaps YADIS does this.

  - RL "Bob"

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 24 Mar 2006 12:57:54 -0800 (PST)

> that doesn't have a GUI, and OpenID can be used that way as well.

Another thing that might be said here is that there's nothing in the SAML 
web browser profiles that requires a UI either.  Though the fact that 
identity-provider discovery is not covered in those profiles (except for 
the Common Domain Cookie approach which is not broadly applicable) does 
mean that in some deployments (not all by any means) a UI is used to do 
discovery.  The YADIS discovery method could well be used to initiate a 
SAML web browser profile flow too (and I think some people might even be 
working on how to do this).

But the SAML browser profiles do require browser features that tend not to 
be found in other HTTP user agents, or to put it in more of standards way, 
are not required to be in them for compliance with the HTTP-based spec 
they are implementing.  It is my impression that these specs (eg WebDAV) 
aren't actually very specific about which HTTP user agent features are 
mandatory (though I could be wrong about that), which if true may need 
fixing.

  - RL "Bob"

---

From: Johannes Ernst <[email-masked]>
Date: Fri, 24 Mar 2006 13:56:30 -0800

On Mar 24, 2006, at 12:57, RL 'Bob' Morgan wrote:

> The YADIS discovery method could well be used to initiate a SAML  
> web browser profile flow too (and I think some people might even be  

I heard the same thing ;-)

By the way, I'm told by the term police (aka Joaquin Miller, of  
NetMesh, the Yadis editor) that I need to tell everybody to spell it  
Yadis, not YADIS, because it isn't an acronym any more, just Yadis.

Johannes Ernst
NetMesh Inc.

---

From: Johannes Ernst <[email-masked]>
Date: Fri, 24 Mar 2006 14:01:07 -0800

On Mar 24, 2006, at 12:26, RL 'Bob' Morgan wrote:
> And, forgive my ignorance, aren't OpenID and LID agnostic about the  
> actual means of authentication performed between the authentication  
> service and the user agent?

Yep.

>   So if someone deploys it using form-based authentication, or  
> taking advantage of some existing form-based authentication, then  
> that would require UI, and would make the system fail to work for  
> non-UI user agents, would it not?  You can say:  well, then don't  
> deploy it that way, use Basic or something; but telling people not  
> to use stuff they like to use isn't a winning strategy usually.

No. The question is 'which is the endpoint that you are  
authenticating?' If, for example, the endpoint is your/on your local  
PC (instead of a Yadis URL out in the cloud, accessible only through  
a browser), you might not need to authenticate again because you  
already did when you logged into your computer.

Which of course brings up the issue of "identity chaining" or  
whatever we'd call it, which surprisingly, has been largely absent  
from this list so far: the use of one identity/persona/whatever to  
authenticate against another identity/persona/whatever and so forth,  
which then becomes the only thing a Relying Party sees; something the  
LID protocol has been able to do for a long while, and that turns out  
to be quite handy ... e.g. in order to log on only once at a single  
service, but still use a number of separate identities/identifiers/ 
personas/whatever hosted by a variety of service providers. I don't  
think anybody has implemented the same thing for OpenID so far, but I  
can't think of a reason it can't be done either without any protocol  
extensions.

> It could be useful to look at standard ways to accomodate GUI and  
> non-GUI user agents each with appropriate methods with the same  
> installations.  Or perhaps YADIS does this.

This turned out to be a beneficial side-effect of Yadis that we did  
not even plan on. Funny, how technology sometimes does that: instead  
of using Yadis 'just" for identity URL discovery, one can also use it  
for Relying Party discovery, and the discovery of which  
authentication protocols a Relying Party supports. (Usually we rely  
on the user to do that discovery by looking at an HTML page where it  
says "you need to have a username and password to authenticate here"  
or "SXIP in" or whatever it says). So Yadis also gives us a "marker"  
for non-GUI-based User Agents for which auth methods are accepted here.

---

From: Johannes Ernst <[email-masked]>
Date: Fri, 24 Mar 2006 14:01:36 -0800

> Can YADIS/LID/OpenID be used to authenticate a WebDAV client to a  
> WebDAV server, for some/most/all of the current typical WebDAV  
> clients and servers?  If so, then you've met the requirement Peter  
> set.

Coincidentally, Brad Fitzpatrick -- the creator of OpenID (and  
LiveJournal) -- just posted on a very related subject just a few days  
ago.

http://brad.livejournal.com/2206769.html

While it is indeed a hack, it would probably work, and applies  
similarly to LID and Yadis.

---

From: John Merrells <[email-masked]>
Date: Mon, 27 Mar 2006 16:14:06 -0800

>    (smartcard/token/whatever) or logical (username/password)  

I don't think you can mandate 'just one', but I think you can mandate
choice. Users should have as few or as many as they feel they need.
As a  real world example think of credit cards. You could have one
but you probably have a back-up or two.

John

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Mar 2006 18:42:17 -0600

> but you probably have a back-up or two.

Agreed, but users shouldn't _have_ to have more than one as a result of
the ad-hoc nature of the systems they use.  I think that is what Robert
was trying to convey, or at least my reading of the particular
requirement I was distilling.

I wouldn't disagree with that...

I suspect users won't mind having multiple tokens, provided that number
is small, as much as having many accounts that require passwords.

Nico
--