Subject: Re: [dix] thoughts on "identity" and IETF

From: Michael Ströder <[email-masked]>
Date: Sun, 04 Dec 2005 14:31:21 +0100

D'Andrew "Dave" Thompson wrote:
> 
> Perhaps we can begin establishing a manner to negotiate differing
> levels of trust need (as I am calling it) and probability thresholds.
> For example, it isn't always necessary that an identity must provide
> date of birth, social security number, etc. Rather, if the mitigating
> risks in a given action are minimal, than the level of trust need is
> lessened. Consequently, a lower probability threshold can be
> established in determining the probability that an identity is indeed
> who they say they are.

Although I think the basic idea heads in the right direction I would not
use the term probability since you cannot determine the exact
probability for identity fraud based on whether a certain user attribute
is known or not. (Maybe some insurance companies could give numbers for
such cases but this is clearly out-of-scope here.)

> For example, if a service is providing authentication/authorization
> for a online newspaper subscription, the risk of any identity gaining
> access to their service is not very high, so perhaps a given
> definition describing their risk level, trust need, and probability
> threshold could allow them to quickly authenticate based upon that
> given context. Whereas a bank's risk level will be much higher
> demanding a greater trust need, and hence a greater probability
> threshold. They could have a standard way of describing this context
> so that a user could provide the required level of identity
> verification.

IMHO DIX should avoid trying to define a risk management framework in a
identity management protocol. This will be either incomplete or too
complex to be widely adopted. Why not just define an extensible protocol
where service providers can specify which attributes (e-mail address,
date of birth, social security number, ID number) they need to determine
the identity.
This should go to the user as a identity claim request and the user
would be prompted to reveal the requested identity attributes (claims?)
and send the identity claim response. (Not sure about the
request/response terminology here.)

> Aside from the benefits of a standard way to discuss contextual
> identity, this would certainly substantiate a more precise legal
> precedence for fraud prosecution based upon risk levels, allowing for
> businesses to mitigate their online risk appropriately and on a
> standard level.

IMHO working out or relying on legal definitions is out-of-scope for
IETF WG activities. Maybe I misunderstood you though. I'm not a native
English speaker.

Ciao, Michael.

-- 
Michael Ströder
http://www.stroeder.com

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

---

From: "THOMAS, BRIAN M \(SBCSI\)" <[email-masked]>
Date: Tue, 13 Dec 2005 16:19:38 -0600

At the risk of confusing and alienating everyone at once, I'd like to try to establish a framework for thinking about the scope of the identity problem we're trying to address.

Many of the discussions I've heard about identity use the same word to refer to vastly different aspects of the real-world problems we face, and I think it's worth some effort to pare the meaning down to what is essential.  This will necessarily be considerably more abstract than any of the systems currently fielded widely, and so some translation will be necessary.

To begin, I think I'll avoid using the word "identity", because although it's the common name for a collection of concepts that looks like the fulfillment of our requirements, it has specific meanings that I believe confuse the issues.

The need, as succinctly as I can express it, is this:

   A simple, flexible, effective and reliable means of expressing and accepting attributes about a communication that permit prudent reliance on the validity of those attributes with respect to that communication.

The standard by which we measure this effort is the set of protocols and practices that are common and well-established in non-networked interactions.

A commercial transaction of the most common, everyday type uses cash to pay for items selected from a shelf.  Note that identity is not involved.  Generally speaking, a merchant does not need to know "who" the buyer is in any meaningful sense.  Nor does the buyer need to know the seller's identity.

At the other end of the spectrum for most of us, the purchase of a house is considerably more involved; not only are the identities of both parties often required, but sworn and notarized statements of numerous attributes of the exchange are involved.

Both exchanges are fundamentally an exchange of value for value.  The first involves little risk, because the values exchanged are small, concrete, and easily verifiable - both buyer and seller have the desired value in hand.  The second involves great risk, because there is great value involved, it's abstract (an unencumbered, defensible title) and difficult to verify.

So the second transaction entails a large and often complex series of individual value transfers with fairly simple parameters.  Some of these include:

A lender actually pays the seller, in exchange for the buyer's promise to repay with interest.  Of course, the obligation to pay does not guarantee the ability to pay, so the buyer also grants an interest in the property, in the form of a lien.  The value of that lien is dependent on the value of the property, so a title insurer guarantees the validity of the seller's title to the property, in exchange for a fee.  In a similar vein, various parties offer services that are aimed largely at mitigating various risks (usually by assuming them) in exchange for a fee.  

In all cases, the "identity" of each party, in the classic sense, is immaterial except as an anchor point for attributes that are necessary to transfer (or otherwise mitigate) risk.  Answering the classic authentication question "is this person who [s]he claims to be?" is necessary only because the claim to "be" someone implies the claim to certain attributes on which the questioner must be able to rely.  In other words, the notary's attestation that the person signing the promissory note "is" John Q. Public, with Social Security number 999-99-9999, is only meaningful because sufficient evidence is available that the person identified thus does not pose an unacceptable risk to the large, abstract and difficult-to-verify value of the transaction.  This evidence consists entirely of attestations of various attributes about the person.

To be acceptable, these attestations must be verifiable as having originated from a party with the proper authority to make them.  "Authority" here, for a robust and flexible system, is absolutely in the eye of the beholder; it means that that particular kind of statement is accepted from that party. This reveals the reflexive nature of the problem, because that "authority" is itself an attribute whose source must be verified.  Ultimately, the final authority comes from the party relying on the information; the seller or the buyer grants, implicitly or explicitly, the authority to the various parties - the various government or professional agencies that certify the bankers, the insurers, the auditors, the notaries, etc.  Even in the cash example, the merchant accepts the bills and coins as "legal tender" primarily because everyone else does, but theoretically because the government backs them, and the customer accepts the reliability of the labeling on the product packages he selects, partly from experience and partly because he knows he can come back and demand a refund, for which he only needs to know where to come.

Thus, in traditional commerce as well as its online analogue, what is needed is not "identity" but a clear and reliable basis for evaluating trustworthiness.  This basis can be represented entirely as assertions, with a reliable means of binding the assertions to their issuers.

So the basic syntax of these assertions or attestations is:

   <attestor> says <something> about <someone>

To make use of these assertions, a party must assemble a chain of them that leads from his own base of policy to the other party and includes the attribute of interest.  If one wishes to automate such an assembly, his machinery must be primed with knowledge of what kinds of assertions will be accepted from which attestors (or is it "testators"?).  This will be the mechanism for policy expression, and indeed can consist of assertions of the same form, as:

  ME says "is trustworthy(score: .87) about credit ratings" about "ACME Ratings & Stuff"

where the score metric could allow computation of credit limits for customers presenting credit ratings issued by this service.  Alternatively, any payment processor, such as a credit card company or PayPal, could be endorsed thus:

  ME says "credit limit: $2000 or customer's credit limit" about "PayPal"

The protocols that would allow for privacy and selective disclosure are therefore very simple:  the merchant (or other party in a "passive" role, that is, one that receives and responds to requests) can simply publicize its offerings with descriptions, prices, and terms, including the various kinds of payments (including, and the customer (or other active requestor) will choose an item based on all these considerations, and offer only the requested credentials.  By the way, with some standard naming, the need to fill in forms with the usual information can be eliminated, because the customer's policies can be expressed as simply and clearly as the merchant's above.

Again, note that "identity" as we usually talk about it does not enter into any of these transactions except when specifically required by one of the parties.  Shipping addresses, account numbers, credit scores and limits, contact information, and scores of other attributes - which do, indeed, add up collecively to a common notion of identity - are needed, but in order to rely on them all that is really needed is reliable testimony, where "reliable" is entirely subjective.  In cases where an identifier is needed that will clearly and reliably identify a legally responsible person for recourse, this can either be done directly or through a proxy that is mutually trusted for the purpose.

The primary requirement, then, for Identity 2.0 is to specify the language for making and accepting these assertions.  The syntax will specify the necessary elements of communication; the semantics will largely be up to the markets to determine, from the industry councils that already maintain standard taxonomies such as metals, fasteners, pipes, wire, paper, etc. to the individual manufacturers of consumer goods, to the wholesalers and retailers, and even the individual users who make up their own ad-hoc goods and services taxonomies.  A number of standards that already exist, such as WS-*, SAML, Dublin Core, and others, ready to be dropped in, mixed and matched, according to the needs of the market.

With these tools, then, individual parties can make their own decisions about "levels" of "trust", probability threshholds, etc.  I have little doubt that gigabytes of actuarial information are available on how those calculations can be made, and thankfully it's not the job of this kind of standards group to standardize those.  Among other things, business models already exist (insurance, credit cards) for making those kinds of calculations and assuming the risks so you don't have to (that's who has all that information, and they make a lot of money from it).

But safety, security and privacy require that the traditional notion of identity - one of whose definitions (from dictionary.com) is "The collective aspect of the set of characteristics by which a thing is definitively recognizable or known" - needs to be atomized into its essential parts, so that a subset of its individual characteristics can be verifiably associated to an individual utterance or a conversation without disclosing any that are not essential to the transaction. 

I hope this hasn't put anyone to sleep, or stated the obvious, or anything antisocial like that.  More, I hope that it has truly defined the problem we seek to solve in a way that makes it possible.

Brian M. Thomas - Senior Technical Architect
SBC Services, Inc.
One SBC Center, Room 24D3
St. Louis, MO 63101
314 235 3141

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Ströder
Sent: Sunday, December 04, 2005 7:31 AM
To: IETF DIX list
Subject: Re: [dix] thoughts on "identity" and IETF

> established in determining the probability that an identity is indeed 

Although I think the basic idea heads in the right direction I would not use the term probability since you cannot determine the exact probability for identity fraud based on whether a certain user attribute is known or not. (Maybe some insurance companies could give numbers for such cases but this is clearly out-of-scope here.)

> so that a user could provide the required level of identity 

IMHO DIX should avoid trying to define a risk management framework in a identity management protocol. This will be either incomplete or too complex to be widely adopted. Why not just define an extensible protocol where service providers can specify which attributes (e-mail address, date of birth, social security number, ID number) they need to determine the identity. This should go to the user as a identity claim request and the user would be prompted to reveal the requested identity attributes (claims?) and send the identity claim response. (Not sure about the request/response terminology here.)

> businesses to mitigate their online risk appropriately and on a 

IMHO working out or relying on legal definitions is out-of-scope for IETF WG activities. Maybe I misunderstood you though. I'm not a native English speaker.

Ciao, Michael.

-- 
Michael Ströder
http://www.stroeder.com

---

From: "Duane Nickull" <[email-masked]>
Date: Tue, 13 Dec 2005 16:27:11 -0800

Hello Thomas / Guten Tag Herr Schroeder:

Es tut mir leid, meine Deitsche ist nicht sehr gute ;-)

I have been lurking on this thread for a bit and would like to chip in a few thoughts.  In general, I would like to suggest a fundamentally different model for how identity and trust are viewed.

Is the concept of "identity" a relic from the tangible world and our inability to think beyond what our eyes see?  My believe is that we only create the illusion of identity and trust while the facts supporting our beliefs are somewhat different.  For example, does having a drivers license from the Washington State Department of Motor Vehicles with the name "Duane Nickull" on it establish my identity as Duane Nickull?  I think the answer is no or somewhat (maybe even "depends"). All it really does is allow you to check the driver's license photo to authenticate me ,which in itself is problematic given it is based on unique looks, and if I pass that test, it tells you that I have successfully passed a process whereby I have satisfied their requirements for being issued that identification.  The level of scrutiny is weighed against the consequences of false positive / false rejection consequences which vary in every event.  It does not mean my name is Duane Nickull carte blanche nor does it guarantee such.  I could have received a drivers license then changed my name and presented my old license.  How does one reconcile those events? 

I believe what may be required is a new high level model for how we view the concepts of entity(being), issuing authority (including attributes of trustworthiness, contact info, type etc), artifact, authentication, credentials, process, date, consequences and events.  The only company I have seen that seems to understand this is SXIP out of Vancouver.

Brief (see referenced white paper for more detail):

An entity (human being) is associated with one or more processes which determine the rights to be issued and use credentials.

Credentials are issued on a certain date by an issuing authority.

In order to receive credentials, you must pass their process.

Entities evaluating credentials scrutinize them based on consequences of mis-authentication.

An entity may subsequently pass their credentials to other entities for authentication, who in turn may validate the credentials and then assign a weight of trustworthiness to the identity.  For example of "weight", a library card from Northern Yemen may be deemed more or less trustworthy than a passport issued by the US.

An "identity" is established by a trail of events whereby an entity has obtained credentials and demonstrates use for purposes with similar or greater consequences with no subsequent problems.  An entity who has used the same identity with several tier one, trusted entities with no problems may be more trustworthy that an entity who has established only one credential and never used it or used it once for an event with lower consequences like obtaining a bus pass.  We need software to track and correlate this data.  I think SXIP is doing something similar to that and wonder why others are so far behind.

So why do we need this?

Because people have more than one identity and having a black and white "you are/are not John Doe" approach is deprecated.  Since a single character or attribute mismatch creates a potential identity mismatch, the odds are very high that an application may have to weigh odds of mismatches in record sets for a single entity.   Being able to ascertain whether or not someone has used a credential with the moniker John Doe by determining what weight of credibility it has is much more in alignment with the goals of those who seek to establish a person's identity.

A group of us wrote a white paper on a new data model for this back in 2001
http://www.nickull.net/whitepapers/Harmonizing_Existing_Data_Models_to_provide_intelligence.pdf

This paper generated a new way of thinking within the intelligence communities.

Duane Nickull (Speaking only for myself, not my employer)

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Ströder
Sent: Sunday, December 04, 2005 7:31 AM
To: IETF DIX list
Subject: Re: [dix] thoughts on "identity" and IETF

Ciao, Michael.

-- 
Michael Ströder
http://www.stroeder.com

---

From: "THOMAS, BRIAN M \(SBCSI\)" <[email-masked]>
Date: Wed, 14 Dec 2005 13:12:48 -0600

Herr Nickull:

By "fundamentally different" I presume you mean different from what is discussed in the message to which you responded.  But other than specifying requirements that are not universal to the problems of managing online identities, and referring to a paper whose purpose was to solve an only marginally related problem, I don't see any truly fundamental difference from the model I described. 

The paper puzzles me somewhat, in that it claims to address the problem of controlling access to records in an aggregated data store, but never actually does, instead discussing the need for, and proposing, a common data format for the records.

Okay, enough snarking; now I'll try to be constructive (isn't caffeine wonderful?).

I believe very strongly (as others have also said, I believe) that the processes that determine and evaluate levels of trustworthiness are not specifiable in a standard of this sort; in order to be usable by a wide variety of entities, it must be recognized that they are highly subjective.  It will be useful for various communities of interest to agree on semantic models for their verification processes, and some of them may actually be important enough to constitute a subtask of this group.  But as one of the Semantic Web people has said (I think), semantics is in the eye of the beholder - and even metadata are subjective.  What I believe that this group must do is to be sure that any reasonably useful semantic model of this sort can be expressed and used in the framework.

Okay, the caffeine is really kicking in now, and I'm beginning to get the shape of your viewpoint.

With respect to the "trail of events", you make a good point.  This is, in accordance with your expressed desire to look at the higher-level aspects of the problem, an example of how these things could be used.  My focus has been on the distillation of common requirements from a great many such use cases, ranging from the childishly simple to the fiendishly complex, and my design philosophy is that the only hope of making complex models that work is to atomize them into the simplest possible elements, as I attempted to do in my earlier discussion.  In this case, a trail of events which collectively suggest a level of trustworthiness can be expressed individually by the involved party or parties and aggregated by the receiver, or they can simply be aggregated by each party and expressed in the aggregate.  Both approaches have tradeoffs, and we ought to resist foreclosing either by specifying the other.  My concern has been with the form of the expressions rather than their content.  A universal standard must specify enough of the form to assure interoperability, and little enough of the content to assure clean applicability to unforeseen situations.

It is also good that you point out that credentials should be dated, because that's one thing I did not discuss, owing to the already embarrassing length of my message.  I deliberately left that out for simplicity's sake, with the understanding that it was properly a part of the <something> said by an <attestor> about <someone>.  Your example suggests that you feel, as I am inclined to, that it is a requirement that is sufficiently universal as to warrant a formal home in the syntax.  However, instead of just an "issue date", much consensus exists to make it a more general specification of not only when it is valid but under what circumstances it should be considered valid - including, for example, a URL for an OCSP-like service to ask for the answer in real time.

I omitted another important element, which is the means of verifying the authenticity of the statement.  Generally, the only practicable means of doing this is with digital signatures, and in light of Doug Royer's "what's wrong" statement (which, by the way, is very good, and I'll be commenting on it soon), I was a little timid about mentioning anything that may strongly imply a PKI requirement.

But since that's out, I may as well confess to co-authorship of RFC2693, and my association with the other RFC that originated in the SPKI WG.  If it wasn't plain already, the addition of the aforementioned items almost completes the picture of the notorious "5-tuple" of SPKI: issuer, subject, authority, delegation, and validity.  I didn't want to bias the group, or be thought to, but I suppose that it may be better to disclose what may be seen as my own bias.  An indivisible part of that "bias" is the absolute conviction that all trust paths are rooted in the relying party.  To me, of course, that's not bias but just good common sense... :-)

On balance, I think we are in agreement (despite my initial annoyance, which is mostly down to feeling slighted, because I didn't think you actually read my message, because I didn't grok your PoV, primarily because of a lack of sleep, which was in no way your fault).  What you describe is a general use case, which I caution is yet not general enough by itself, but still quite valid and useful.

A side note:  Being, as your signature claims, an OASIS TC chair, you are doubtless aware of another OASIS recommendation, the Common Alerting Protocol, designed for reporting various public-safety situations.  This is one possible version of the "event" model your paper discusses, and quite possibly of the assertions I've described.  Generally, of course, I see these assertions being positive, being presented by the subject to support attribute claims, whereas a CAP message reporting a crime is a negative one.

But this kind of message demonstrates an important facet of DIX's problem space:  Though there is potentially great value in giving the citizen-in-the-street access to reporting capabilities, and many are considering doing so, conflicting requirements include the need to infer a confidence level from the context and attributes of the report, the (at least perceived) need to deter pranks and other malicious misreporting by potentially punitive means, and the very real need for anonymity on the part of witnesses to crimes.  Another conflict, maybe not resolvable by technical means, arises from the value of being able to contact the witness for further interrogation.  A means of verifying various confidence-relevant attributes of the reporter (such as, for example, physical proximity to the putative crime scene, or a history of crying "wolf", or mental illness, or a suspiciously coincidental criminal record) without necessarily providing information that could aid a criminal seeking reprisal.  As others have mentioned, and as I illustrate below, purely deterministic algorithmic calculations of reliability are seldom feasible.

CAP message processing generally would do a lot of correlating and corroborating, SNMP- or CMIP-style, to handle a lot of the confidence calculations, which works nicely with your "event" model.  In many cases, however, the reports are reviewed by professional experts, and the only message forwarded to most places is one initiated by the highly-reliable human expert.  It may be that deterrence options may be foregone because of this and its conflict with anonymity.  I suspect, though, that not only will different processors have different policies on this, but the same processor could well decide to change policies with experience (or legislation, considering the controversial nature of some of my examples), and it would be a Really Bad Idea to fix this choice in a standard.

I'd like your opinion (and others, need it be said?) on how you feel this use case is satisfied by the strawman proposal.  I'd also like to apologize for once again sending a message of eyeball-glazing length...

And I haven't yet seen the proposed charter - did I miss a message, or may I reasonably infer that life is similarly chaotic for the proposer as for me?

brain[sic] 

-----Original Message-----
From: Duane Nickull [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2005 6:27 PM
To: THOMAS, BRIAN M (SBCSI); Michael Ströder; IETF DIX list
Subject: RE: [dix] thoughts on "identity" and IETF

So why do we need this?

A group of us wrote a white paper on a new data model for this back in 2001 http://www.nickull.net/whitepapers/Harmonizing_Existing_Data_Models_to_provide_intelligence.pdf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Dec 2005 14:35:05 -0800

I get a bit nervous when we start talking about solving problems like 'identity'. We seem to spend so much time arguing over what the problem is.

We have no shortage of technology. In fact we probably have too much.

I recently saw a proposal for a negotiation layer on top of gssapi, sasl, saml. NO! Just pick one.

We need to see the problem from the user point of view. 

I keep sitting through presentations on identity that leave me wondering what the heck is going on. 

I want to know two things, what does the user see? and what bits go on the wire?

 -----Original Message-----
From: 	THOMAS, BRIAN M (SBCSI) [mailto:[email-masked]]
Sent:	Wed Dec 14 11:15:25 2005
To:	Duane Nickull; IETF DIX list
Subject:	RE: [dix] thoughts on "identity" and IETF

Herr Nickull:

brain[sic] 

-----Original Message-----
From: Duane Nickull [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2005 6:27 PM
To: THOMAS, BRIAN M (SBCSI); Michael Ströder; IETF DIX list
Subject: RE: [dix] thoughts on "identity" and IETF

So why do we need this?

---

From: "THOMAS, BRIAN M \(SBCSI\)" <[email-masked]>
Date: Wed, 14 Dec 2005 18:21:49 -0600

Phill:

The user sees his own bits of information, tagged with descriptions that
are clearly understandable, plus all those offered or requested by any
other user, with equally understandable descriptions, so that he can
intelligently and confidently match up the ones that have the same
meaning, and that he wants to share or request, with as little risk of
unexpected consequences as possible.

He sees a simple set of tools to express his desires regarding who gets
to see what and under what circumstances, so that the reading,
understanding, and filling in of lengthy and tedious web forms is
drastically reduced, to the point where the simplest and most routine
transactions can be initiated at the press of a button or the firing of
a timer, or in response to some outside, even unexpected event.

To do this, the bits that go on the wire can't be specified beforehand
because they can't even be known.  As far as I can tell, "just pick one"
is not an option.

There is, as you say, no shortage of technology, and many of the
technologies that are useful to attribute assertions are widely deployed
for other purposes.  The protocols already mentioned - SAML, CAP, WS-*,
and even GSSAPI, plus far too many more to mention, with more coming all
the time - contain, as part of their purpose, many of the bits of
information that are needed, and from the authoritative sources.  

Network effects are enabled and even amplified when simple lexical
standards like XML underlie the bulk of the protocols, making it
possible, in a simple and reliable way, to extract those bits without
requiring the cooperation, permission or even the knowledge of the
providers of the data.  For the steadily shrinking set of widely-used
protocols that are both useful and not based on this standard, adapters
can be crafted.  I've done a lot of this kind of work myself, so much so
that it got boring and I worked with a group that automated it using a
free Java-based tool as a base.

As a largely unrelated but very similar example, consider the Firefox
extensions protocol and the hundreds of (mostly) very useful extensions
that exist for it today, created by hundreds of individuals.  Closer to
the point I'm making, there is the Firefox search plugin specification,
which by now has likely thousands of instances, created by people with
little or no connection either to Mozilla or the resources they
searched.  Hundreds of Javascript "bookmarklets", along with the
extensions, make me look like a bloody magician to the typical IE user
who looks over my shoulder.  Tag a webpage?  I never visit the
del.icio.us website, except for PDF docs that don't support Javascript.
Mail a scrap of text from a website to a colleague?  Don't cut and
paste, or even drag and drop; select it and click a bookmarklet.  Look
up an unfamiliar word from a page?  Select it and double-click or hit a
key.  Create a new blog entry? Don't go to the blog site and navigate to
the edit window; just click BlogThis!, optionally selecting your
starting text first from a page.

And for a direct example of exactly what I'm talking about, the Simile
project at MIT (simile.mit.edu) offers an explicit description and
explanation of the what, how, and why behind some of the buzz around
trendy new concepts like "mashups" and "remixing the Web", but with the
more formal support of the SemanticWeb structure.

So while I probably agree that the proposal you rejected was
wrong-headed, my reason would be opposite to yours in that it was too
specific, and therefore too limited.  Also, because (if my inference
from your description is correct) it tried to usurp the user's choices,
believing it to be a necessary part of shielding him from the
complexities.

I believe that it is those things that we need to understand, and for a
starting place I am proposing the formal semantic metamodel of SPKI, and
leaving the syntax and the specific semantics to the users.

brain[sic] 

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Wednesday, December 14, 2005 4:35 PM
To: THOMAS, BRIAN M (SBCSI); Duane Nickull; IETF DIX list
Subject: RE: [dix] thoughts on "identity" and IETF

I get a bit nervous when we start talking about solving problems like
'identity'. We seem to spend so much time arguing over what the problem
is.

I recently saw a proposal for a negotiation layer on top of gssapi,
sasl, saml. NO! Just pick one.

I keep sitting through presentations on identity that leave me wondering
what the heck is going on.

I want to know two things, what does the user see? and what bits go on
the wire?