From dix-bounces@ietf.org Mon Dec 05 13:05:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjKiX-00020t-6X; Mon, 05 Dec 2005 13:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjKiV-0001xK-2t for dix@megatron.ietf.org; Mon, 05 Dec 2005 13:05:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21510 for ; Mon, 5 Dec 2005 13:04:43 -0500 (EST) Received: from 179-17-124-83.dsl.3u.net ([83.124.17.179] helo=srv1.int.stroeder.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjL3m-000365-Rp for dix@ietf.org; Mon, 05 Dec 2005 13:27:36 -0500 Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id B3DFC2C7F for ; Mon, 5 Dec 2005 19:05:03 +0100 (CET) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22894-05 for ; Mon, 5 Dec 2005 19:04:53 +0100 (CET) Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Stroeder", Issuer "Thawte Personal Freemail Issuing CA" (not verified)) by srv1.int.stroeder.com (Postfix) with ESMTP id 080842C7B for ; Mon, 5 Dec 2005 19:04:52 +0100 (CET) Message-ID: <4392EFA9.8050905@stroeder.com> Date: Sun, 04 Dec 2005 14:31:21 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF DIX list Subject: Re: [dix] thoughts on "identity" and IETF References: <437659AB.80109@secure-endpoints.com> <7b297ea20511141815k3b1b2051r79ab1081f59a6a43@mail.gmail.com> In-Reply-To: <7b297ea20511141815k3b1b2051r79ab1081f59a6a43@mail.gmail.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: amavisd-new at int.stroeder.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org D'Andrew "Dave" Thompson wrote: >=20 > 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. --=20 Michael Str=F6der http://www.stroeder.com _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Dec 13 17:20:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIVS-00051C-3C; Tue, 13 Dec 2005 17:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIVE-0004uo-2y for dix@megatron.ietf.org; Tue, 13 Dec 2005 17:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07472 for ; Tue, 13 Dec 2005 17:18:58 -0500 (EST) Received: from sbcsmtp3.sbc.com ([144.160.112.11] helo=tlph033.enaf.dadc.sbc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmIW6-00057A-9Z for dix@ietf.org; Tue, 13 Dec 2005 17:21:03 -0500 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBDMJjPn011198; Tue, 13 Dec 2005 16:19:45 -0600 Received: from MOSTLS1MSGHUB03.ITServices.sbc.com (mostls1msghub03.itservices.sbc.com [132.201.19.8]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBDMJeWb011133; Tue, 13 Dec 2005 16:19:40 -0600 Received: from MOSTLS1MSGUSR12.ITServices.sbc.com ([132.201.19.63]) by MOSTLS1MSGHUB03.ITServices.sbc.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Dec 2005 16:19:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Tue, 13 Dec 2005 16:19:38 -0600 Message-ID: <5BCA148CF620434585515BA6EB61B8600287604C@MOSTLS1MSGUSR12.ITServices.sbc.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bA From: "THOMAS, BRIAN M \(SBCSI\)" To: =?iso-8859-1?Q?Michael_Str=F6der?= , "IETF DIX list" X-OriginalArrivalTime: 13 Dec 2005 22:19:40.0015 (UTC) FILETIME=[4F48EFF0:01C60033] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.5.1048-14142.000 X-TM-AS-Result: No--112.680000-0.000000-2 X-Spam-Score: 0.9 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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. =20 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: says about 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.=20 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 =20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of = Michael Str=F6der Sent: Sunday, December 04, 2005 7:31 AM To: IETF DIX list Subject: Re: [dix] thoughts on "identity" and IETF D'Andrew "Dave" Thompson wrote: >=20 > Perhaps we can begin establishing a manner to negotiate differing=20 > levels of trust need (as I am calling it) and probability thresholds.=20 > For example, it isn't always necessary that an identity must provide=20 > date of birth, social security number, etc. Rather, if the mitigating=20 > risks in a given action are minimal, than the level of trust need is=20 > lessened. Consequently, a lower probability threshold can be=20 > established in determining the probability that an identity is indeed=20 > 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=20 > for a online newspaper subscription, the risk of any identity gaining=20 > access to their service is not very high, so perhaps a given=20 > definition describing their risk level, trust need, and probability=20 > threshold could allow them to quickly authenticate based upon that=20 > given context. Whereas a bank's risk level will be much higher=20 > demanding a greater trust need, and hence a greater probability=20 > threshold. They could have a standard way of describing this context=20 > so that a user could provide the required level of identity=20 > 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=20 > identity, this would certainly substantiate a more precise legal=20 > precedence for fraud prosecution based upon risk levels, allowing for=20 > businesses to mitigate their online risk appropriately and on a=20 > 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. --=20 Michael Str=F6der http://www.stroeder.com _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Dec 13 19:26:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKTv-0000ej-Kn; Tue, 13 Dec 2005 19:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKTt-0000cb-M6 for dix@megatron.ietf.org; Tue, 13 Dec 2005 19:26:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24257 for ; Tue, 13 Dec 2005 19:25:55 -0500 (EST) Received: from exprod6mx60.postini.com ([64.18.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmKUx-0002WL-AZ for dix@ietf.org; Tue, 13 Dec 2005 19:28:02 -0500 Received: from source ([192.150.20.142]) by exprod6ob13.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 13 Dec 2005 16:26:42 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBE0QcFX004016; Tue, 13 Dec 2005 16:26:38 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBE0Qarw025194; Tue, 13 Dec 2005 16:26:39 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 16:27:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Tue, 13 Dec 2005 16:27:11 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E4527C7B@namail3.corp.adobe.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pA= From: "Duane Nickull" To: "THOMAS, BRIAN M \(SBCSI\)" , =?iso-8859-1?Q?Michael_Str=F6der?= , "IETF DIX list" X-OriginalArrivalTime: 14 Dec 2005 00:27:50.0069 (UTC) FILETIME=[36EA0E50:01C60045] X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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?=20 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_pr= ovide_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/ *******************************=20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of = THOMAS, BRIAN M (SBCSI) Sent: Tuesday, December 13, 2005 2:20 PM To: Michael Str=F6der; IETF DIX list Subject: RE: [dix] thoughts on "identity" and IETF 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. =20 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: says about 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.=20 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 =20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of = Michael Str=F6der Sent: Sunday, December 04, 2005 7:31 AM To: IETF DIX list Subject: Re: [dix] thoughts on "identity" and IETF D'Andrew "Dave" Thompson wrote: >=20 > Perhaps we can begin establishing a manner to negotiate differing=20 > levels of trust need (as I am calling it) and probability thresholds.=20 > For example, it isn't always necessary that an identity must provide=20 > date of birth, social security number, etc. Rather, if the mitigating=20 > risks in a given action are minimal, than the level of trust need is=20 > lessened. Consequently, a lower probability threshold can be=20 > established in determining the probability that an identity is indeed=20 > 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=20 > for a online newspaper subscription, the risk of any identity gaining=20 > access to their service is not very high, so perhaps a given=20 > definition describing their risk level, trust need, and probability=20 > threshold could allow them to quickly authenticate based upon that=20 > given context. Whereas a bank's risk level will be much higher=20 > demanding a greater trust need, and hence a greater probability=20 > threshold. They could have a standard way of describing this context=20 > so that a user could provide the required level of identity=20 > 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=20 > identity, this would certainly substantiate a more precise legal=20 > precedence for fraud prosecution based upon risk levels, allowing for=20 > businesses to mitigate their online risk appropriately and on a=20 > 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. --=20 Michael Str=F6der http://www.stroeder.com _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Dec 14 14:13:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emc3y-0002Do-MV; Wed, 14 Dec 2005 14:13:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emc3w-0002DU-FV for dix@megatron.ietf.org; Wed, 14 Dec 2005 14:13:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12126 for ; Wed, 14 Dec 2005 14:12:15 -0500 (EST) Received: from sbcsmtp3.sbc.com ([144.160.112.11] helo=tlph033.enaf.dadc.sbc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emc58-0004dl-Tb for dix@ietf.org; Wed, 14 Dec 2005 14:14:31 -0500 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBEJCsqH004310; Wed, 14 Dec 2005 13:12:54 -0600 Received: from MOSTLS1MSGHUB03.ITServices.sbc.com (mostls1msghub03.itservices.sbc.com [132.201.19.8]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBEJCpXv004297; Wed, 14 Dec 2005 13:12:51 -0600 Received: from MOSTLS1MSGUSR12.ITServices.sbc.com ([132.201.19.63]) by MOSTLS1MSGHUB03.ITServices.sbc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Dec 2005 13:12:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Wed, 14 Dec 2005 13:12:48 -0600 Message-ID: <5BCA148CF620434585515BA6EB61B8600287618E@MOSTLS1MSGUSR12.ITServices.sbc.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsA== From: "THOMAS, BRIAN M \(SBCSI\)" To: "Duane Nickull" , "IETF DIX list" X-OriginalArrivalTime: 14 Dec 2005 19:12:50.0027 (UTC) FILETIME=[600643B0:01C600E2] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.5.1048-14143.000 X-TM-AS-Result: No--119.335000-0.000000-2 X-Spam-Score: 0.9 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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.=20 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 said by an about . 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]=20 -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com]=20 Sent: Tuesday, December 13, 2005 6:27 PM To: THOMAS, BRIAN M (SBCSI); Michael Str=F6der; IETF DIX list Subject: RE: [dix] thoughts on "identity" and IETF 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?=20 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_pr= ovide_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/ *******************************=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Dec 14 17:35:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmfDc-0004Ui-Fq; Wed, 14 Dec 2005 17:35:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmfDZ-0004R9-Kd for dix@megatron.ietf.org; Wed, 14 Dec 2005 17:35:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07251 for ; Wed, 14 Dec 2005 17:34:19 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmfEi-0004N4-9N for dix@ietf.org; Wed, 14 Dec 2005 17:36:37 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id jBEMZ89P021482; Wed, 14 Dec 2005 14:35:08 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 14:35:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] thoughts on "identity" and IETF Date: Wed, 14 Dec 2005 14:35:05 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD375A2BD5@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsAAR96nH From: "Hallam-Baker, Phillip" To: "THOMAS, BRIAN M \(SBCSI\)" , "Duane Nickull" , "IETF DIX list" X-OriginalArrivalTime: 14 Dec 2005 22:35:06.0299 (UTC) FILETIME=[A1CE68B0:01C600FE] X-Spam-Score: 1.1 (+) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0849002649==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0849002649== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C600FE.A1A028F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C600FE.A1A028F7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.=20 I keep sitting through presentations on identity that leave me wondering = what the heck is going on.=20 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:bt0008@sbc.com] Sent: Wed Dec 14 11:15:25 2005 To: Duane Nickull; IETF DIX list Subject: RE: [dix] thoughts on "identity" and IETF 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.=20 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 said by an about . 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]=20 -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com]=20 Sent: Tuesday, December 13, 2005 6:27 PM To: THOMAS, BRIAN M (SBCSI); Michael Str=F6der; IETF DIX list Subject: RE: [dix] thoughts on "identity" and IETF 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?=20 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_pr= ovide_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/ *******************************=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ------_=_NextPart_001_01C600FE.A1A028F7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.

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:bt0008@sbc.com]
Sent:   Wed Dec 14 11:15:25 2005
To:     Duane Nickull; IETF DIX list
Subject:        RE: [dix] thoughts on = "identity" and IETF

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:dnickull@adobe.com]
Sent: Tuesday, December 13, 2005 6:27 PM
To: THOMAS, BRIAN M (SBCSI); Michael Str=F6der; IETF DIX list
Subject: RE: [dix] thoughts on "identity" and IETF


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/Harmon= izing_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= /
*******************************

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org= /mailman/listinfo/dix

------_=_NextPart_001_01C600FE.A1A028F7-- --===============0849002649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0849002649==-- From dix-bounces@ietf.org Wed Dec 14 19:22:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgst-00038D-PC; Wed, 14 Dec 2005 19:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgss-00037O-Nm for dix@megatron.ietf.org; Wed, 14 Dec 2005 19:22:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18317 for ; Wed, 14 Dec 2005 19:21:11 -0500 (EST) Received: from sbcsmtp3.sbc.com ([144.160.112.11] helo=tlph033.enaf.dadc.sbc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emgu9-0008Of-MY for dix@ietf.org; Wed, 14 Dec 2005 19:23:31 -0500 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBF0LsdI004763; Wed, 14 Dec 2005 18:21:54 -0600 Received: from MOSTLS1MSGHUB03.ITServices.sbc.com (mostls1msghub03.itservices.sbc.com [132.201.19.8]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id jBF0Loep004743; Wed, 14 Dec 2005 18:21:50 -0600 Received: from MOSTLS1MSGUSR12.ITServices.sbc.com ([132.201.19.63]) by MOSTLS1MSGHUB03.ITServices.sbc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Dec 2005 18:21:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Wed, 14 Dec 2005 18:21:49 -0600 Message-ID: <5BCA148CF620434585515BA6EB61B86002876282@MOSTLS1MSGUSR12.ITServices.sbc.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsAAR96nHAAA6iAA= From: "THOMAS, BRIAN M \(SBCSI\)" To: "Hallam-Baker, Phillip" , "Duane Nickull" , "IETF DIX list" X-OriginalArrivalTime: 15 Dec 2005 00:21:50.0302 (UTC) FILETIME=[8AE3B7E0:01C6010D] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.5.1048-14144.000 X-TM-AS-Result: No--114.589000-0.000000-2 X-Spam-Score: 2.9 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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. =20 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]=20 -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 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. 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? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Dec 14 21:49:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmjB6-0008EM-4v; Wed, 14 Dec 2005 21:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmjB1-0008Dc-Tj for dix@megatron.ietf.org; Wed, 14 Dec 2005 21:49:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01602 for ; Wed, 14 Dec 2005 21:47:56 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmjCA-0004qi-ON for dix@ietf.org; Wed, 14 Dec 2005 21:50:16 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jBF2mesl024347; Wed, 14 Dec 2005 18:48:40 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 18:48:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Wed, 14 Dec 2005 18:48:39 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37823A7F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsAAR96nHAAA6iAAAB/J0kA== From: "Hallam-Baker, Phillip" To: "THOMAS, BRIAN M \(SBCSI\)" , "Duane Nickull" , "IETF DIX list" X-OriginalArrivalTime: 15 Dec 2005 02:48:40.0439 (UTC) FILETIME=[0E23F070:01C60122] X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org =20 > From: THOMAS, BRIAN M (SBCSI) [mailto:bt0008@sbc.com]=20 > The user sees his own bits of information, tagged with=20 > descriptions that are clearly understandable, plus all those=20 > offered or requested by any other user, with equally=20 > understandable descriptions, so that he can intelligently and=20 > confidently match up the ones that have the same meaning, and=20 > that he wants to share or request, with as little risk of=20 > unexpected consequences as possible. We tried that with P3P. The problem with this approach is that it requires the user to do more than they are prepared to do which is vanishingly close to 'nothing at all'. I am very skeptical about the assertion that the user wants to really give out the information at all, or for that matter there is as much interest in the data requested as the inferences that can be drawn from it. > To do this, the bits that go on the wire can't be specified=20 > beforehand because they can't even be known. As far as I can=20 > tell, "just pick one" > is not an option. I agree people want flexibility, but this was the starting point for SAML, GSSAPI, SASL. It is time to say 'choose one negotiation infrastructure, the existence of 6 negotiation standards does not mean there is value to supporting more than one. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Dec 15 02:11:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmnHK-00077h-BA; Thu, 15 Dec 2005 02:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmnHC-00076i-CW for dix@megatron.ietf.org; Thu, 15 Dec 2005 02:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24968 for ; Thu, 15 Dec 2005 02:10:31 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmnIM-0005AV-80 for dix@ietf.org; Thu, 15 Dec 2005 02:12:54 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBF7BIaH000486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Dec 2005 02:11:18 -0500 (EST) Message-ID: <43A116FC.8030403@secure-endpoints.com> Date: Thu, 15 Dec 2005 02:10:52 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Subject: Re: [dix] thoughts on "identity" and IETF References: <198A730C2044DE4A96749D13E167AD37823A7F@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD37823A7F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.93.2.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: IETF DIX list X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536840880==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0536840880== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070000070800040901000007" This is a cryptographically signed message in MIME format. --------------ms070000070800040901000007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > I agree people want flexibility, but this was the starting point for > SAML, GSSAPI, SASL. It is time to say 'choose one negotiation > infrastructure, the existence of 6 negotiation standards does not mean > there is value to supporting more than one. > Speaking as Chair of the Kitten (GSSAPI Next Generation) working group, what many of us have been saying for a long time is that applications should when possible develop to SASL because it provides the ability to construct post authentication security layers (data privacy and integrity protection) and mechanism implementors should implement their mechanisms within the GSSAPI framework. All GSS mechanisms can be used within SASL. There is a strong desire to be able to specify a unified mechanism specification which would allow mechanisms consistent with such a specification to be utilized by EAP as well. It is important to point out that this flexibility is necessary for mechanism implementors. There is absolutely no reason why an application protocol should accept more than one of SASL, GSS, EAP, etc. In fact, allowing for the use of multiple security context negotiation protocols within an application will almost always introduce downgrade attacks. There has been discussion of implementing a GSS mechanism for SAML. There is also discussion within the Kerberos communicating of transporting SAML within the authorization data field of the Kerberos service tickets. Kitten is looking at extending GSS to support stackable mechanisms so that a generic SAML mechanism could be piggybacked on top of existing authentication mechanisms. One thing that concerns me about the terminology within this discussion is that the concept of "identity" being discussed is not one that is appropriate for use in performing authentication and the establishment of secure (private and integrity protected) communication channels. In the early days of JXTA we discussed a great deal the concept of peer-to-peer trust models. Look for the early Poblano papers. One of the things that we agreed very early on is that distributed trust is orthogonal to authentication. I also have a problem with the terminology being used. Are we really trying to say that an entity has multiple "identities"? As far as I know, I have only one identity, "me". What I do have many of are forms of identification which include government issued IDs (driver's license, passport, birth certificate, gun permit, etc), university issued IDs, employer issued IDs, e-mail addresses, banking related IDs (credit and check cards), X.509 certificates, Kerberos principals, etc. I imagine a world in which, for example, every machine with local accounts on it is its own Kerberos realm that manages the client principals for the local accounts. Elsewhere in the world are service providers that have their own realm that manages service principals for each of their services (blogs, photo libraries, etc.). The client realm and the service realms are able to authenticate to each other via Kerberos cross-realm where key sharing is performed using public key cryptography. Similar to the PGP model, the trust value of the cross-realm relationship is configured by human beings. A cross-realm relationship in which two administrators inspected each other's environments and manually setup keys could be given a high trust value; others which were established after validating X.509 certificates might be given a medium trust value, and others that were established with anonymous public key crypto would be given a very low level of initial trust. A bank might establish the cross-realm relationship but not allow that locally managed identification to be used for anything significant without additional forms of verification. One thing that is absolutely true is that we are never going to be in a world in which an entity has only a single form of identification. I already manage dozens of Kerberos principals and X.509 certificates that are used for authenticating to services at various organizations. If it were the case that only one form of identification could be used with any one service, then implementing a search algorithm to choose the appropriate form of identification for authenticating to that service would be easy. Where the fun starts is when it is possible to use multiple forms of identification with a specific service that associates each form of identification with a different role. It then becomes extremely difficult to develop the necessary associations between identifications and services to automate the process for the user and make accurate choices based upon the user's needs at the given moment. On the other hand if you try to involve the user in the decision making process for each authentication, the user will find the software unusable. One real world example is the Andrew File System. AFS uses Kerberos for authentication and cross- realm relationships are used to allow an ATHENA.MIT.EDU Kerberos client principal to obtain a Kerberos service ticket for afs/andrew.cmu.edu@ANDREW.CMU.EDU. Now as it turns out due to the cross-realm relationships how should my local tools decide which of my many Kerberos principals that can obtain the necessary service ticket should be used to do so? jaltman@ATHENA.MIT.EDU jaltman@RAEBURN.ORG jaltman@SECURE-ENDPOINTS.COM jaltman@WINDOWS.SECURE-ENDPOINTS.COM jaltman/admin@SECURE-ENDPOINTS.COM jaltman@DEMENTIA.ORG jaltman@ANDREW.CMU.EDU They would all work and at the present time each one would result an authentication as a separate AFS ID where the AFS ID is the thing placed in an ACL. One of the ways in which we are going to address this problem is by making the end user tools smart so they can be told, unless told otherwise when accessing the "andrew.cmu.edu" AFS cell, the jaltman@SECURE-ENDPOINTS.COM principal name should be used. Secondly, we are adding functionality to the AFS Protection Service that will allow multiple identifications to be associated with a single AFS ID, where an identification is defined as an authentication type and name pair (such as Kerberos 5, jaltman@SECURE-ENDPOINTS.COM). I believe that by approaching the problem from both sides in this manner it will be possible for us to construct an extremely user friendly environment that allows users to access services at various times and from various places with different sets of available forms of identification. Service providers will determine for themselves which forms of identification are acceptable for which tasks based upon their own risk assessments. I believe the most important thing to realize is that solving the problem does not require throwing out what we have already built. The existing authentication infrastructures can be extended to meet the needs of the broader community. Jeffrey Altman --------------ms070000070800040901000007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEyMTUwNzEwNTJaMCMGCSqG SIb3DQEJBDEWBBTuOgKh4sjI7ei3OMNZhYsvRpHpLzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQB+tGagih8JM9TWx1hCOCORPrAxWlnzAfjzhxXyihMF2ujYRwaAr2vxkab/pZ9fTzGDB61E jUU5Qol2l7pgbckRLGuwheAR5NcpsusH7svHQ+ZU251VhiPHhrQ+4XYJ3bhKsp9cL++F2AoG 8KVN2XT8DHm0YwHN0fn7MLU6I6jFQsXUhki/7FBLza6wB/pufptg7wcf9WbNV1Y3MGO4pfli pTdftlR+o02E4kWSRArIMJNJLDYdUwARfnxQ5naTNx7R5/TYrGR/E+csxMGf96YWE+25uwRD 7SvgpWD/ABs7I1YBk3eB42mFVYgBDK15KuvoCB3vnAz2k+eFPgjLeas7AAAAAAAA --------------ms070000070800040901000007-- --===============0536840880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0536840880==--