23 Jun 2007 02:20

### Algorithm

```
Hi,
Is this yet discovered? :

1. Given a "potential value" of a given number made of digits, wich is the
reduction to one digit by succesive sum of its digits.
2. This value repeats in an interval (-(base-1)) - 0 - (base-1)
3. Let's call "weight" of a digit in the expression: (base pow
positionDigit) * digit
4. Assigning identifiers, given the case, in a specific interval it happens
that:
a. Given three nodes, left, right and parent with respective identifiers.
b. Maybe func(potentialValue(leftNodeID), potentialValue(rightNodeID)) ==
func(potentialValue(parentNodeID))

It's just an idea to develop how in a graph, reduced to a binary tree, one
can, for example, calculate regarding only in node identifiers, if two nodes
are interconnected and in how many and which type of leaps.

Regards,
--
[first: sebastián] [last: samaruga]
[email: tianxama <at> gmail.com]
[url: http://www.simetris.com.ar]
--

--
View this message in context: http://www.nabble.com/Algorithm-tf3967603.html#a11262055
Sent from the IETF - dix mailing list archive at Nabble.com.
```
12 Jun 2007 03:30

### identification semantics algorithm

http://www.simetris.com.ar

## Part-Whole relationships. Part(s) describing surronding Whole.

The idea is to develop kind of data structure, with parts nested compounding a whole, and the inner parts of the structure knows, in reverse order, the containing tree of elements or structure surrounding it.

### 1: Definitions:

1. superPart: Part containing one or more parts.
2. part: Inside a superPart. Can contain subParts.
3. subPart: Inner unit inside a part.
4. NID: Nesting level ID (deep level entities are in a nested/tree structure)

XML Example:

<superPart NID="0"> <part NID="1"> <subPart NID="2"> </part> <!-- end NID 1 --> </superPart> <!-- end NID 0 -->
5. SeqID: Sequence ID (symbol sequencing and identification)

Symbols sequencing and identification begins with first occurrence of a symbol in a structure, begining with 0, next symbol is tagged with 1. If next symbol appeared before, then the tag used before to identify it is used.

6. OccID: Occurrence ID

Times element appeared in a sequence. First time same element occurs is 0, then 1, etc.

7. CID: Count ID (0, 1, 2, ...)

Sequential count, begining with 0, of elements in determinate context (Nesting level, Sequence, etc.)

8. MvtID: Movement ID

Signals start (S), inside (I), outside (O) or end (E) movement in a statement chain.

### 2. Example:

• Linear Form:
( superPart ( part ( ( superPart ) ( subPart ( part ( superPart ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 MvtID: S I O I O E
• XML Example:
<superPart NID="0"> <part NID="1"> <superPart NID="2"/> <subPart NID="2"> <part NID="3"> </superPart NID="4"> </part> </subPart> </part> </superPart>
• Another Example:
( head ( face ( ( head ) ( eyes ( face ( head ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 MvtID: S I O I O E

### 3. Composite IDs:

Combining CID, NID, SeqID and OccID, other IDs for easier retrieval of elements in statement can be achieved.

For example: NID + OccID = CID (Count of elements inside a specific nesting level)

( head ( face ( ( head ) ( eyes ( face ( head ) ) ) ) ) NID: 0 1 2 2 3 4 SeqID: 0 1 0 2 1 0 OccID: 0 0 1 0 1 2 CID: 0 1 2 3 4 5 OrderID: (0.0) (1.0) (2.0) (2.1) (3.0) (4.0)

### 4. Terms (Parts) Relationships and Roles:

In specific context of container part, another part plays a role or function in the context of container part. This is the semantics of the containment relationship, for example: John, inside a specific Team, is a player, more specificaly, a goalkeeper.

Parsing Example:

[previousElement]:[role/type] => [actualElement]:[role/type] => [nextElement]:[role/type]

### 5. Measurement units:

superUnit (eg.: Kilometer) unit (eg.: Meter) subUnit (eg.: Centimeter) Ratio: superUnit (1) => unit (1/n) => subUnit (1/n : n)

In a specific Context which contains Type(s) of entities, one Entity playing a specific Role (which are part of a Type definition) have one and only Identifier which determines its identity.

Context := [Type]* Type := [Role]* Role := [Entity]* Entity := [PlayerType] [ActorType] => (Identity) PlayerType := 'sender' | receiver ActorType := 'active' | 'pasive'

In a Dialog made of Statement(s) which are compound with Term(s), the Identity of a Player/Actor determines which Role the entity plays, determined with it's Type interactions/operations (Message*).

[ Research > > Algorithms ]
ENGLISH: Symbols sequencing/identification (stream): 1. Map sucesive symbols with numbers (starting at 0) 2. Symbol repeated, use the identifier used the first time the simbol appeared 3. After a repeated symbol, continue with id sequence if next symbol is new, use last otherwise 4. Apply recursively from contained symbol structures to containers (letter / word ; word / sentence) Example: String: ASDFAEIOUS Encoding: 0123045671 Part-Whole Composition Rules: ---------------------------- 1. Letter - Word = SINTAX 2. Word - Statement = GRAMMAR SINTAX- META-MODEL GRAMMAR - MODEL One level sintax is next level grammar. Symbol sequencing: 1. Rules by symbols order of occurence 2. ALPHABET Construction (META-MODEL) 3. DICTIONARY Construction (MODEL) SPANISH: Secuenciamiento Simbolos cadena/stream (Algoritmo): 1. Identificar simbolos con secuencia numérica (comenzando desde 0) 2. Al repetirse simbolo, repetir identificador previamente usado 3. Luego de repetirse simbolo, si el simbolo subsiguiente es nuevo, utilizar identificador siguiente en secuencia 4. Aplicar identificacion simbolos recursivamente (ej.: letras > palabras > oraciones) Ejemplo: Cadena: ASDFAEIOUS Encoding: 0123045671 Reglas de composición Parte-Todo: -------------------------------- 1. Letra - Palabra = SINTAXIS 2. Palabra - Oración = GRAMATICA SINTAXIS- META-MODELO GRAMATICA - MODELO Recursividad: La sintaxis de un nivel es la gramatica del nivel subsiguiente. Secuenciamiento de símbolos: 1. Reglas segun orden de aparicion simbolos. 2. Construccion de ALFABETO (META-MODELO) 3. Construccion de DICCIONARIO (MODELO)
View this message in context: identification semantics algorithm
Sent from the IETF - dix mailing list archive at Nabble.com.
```_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix
```
19 Oct 2006 20:30

### RE: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport

Andy,
I think it is incredibly useful in showing the technology needed to help protect users with systems like this.  I'd love to see it as part of the Heraldry project, you are already a committer, assuming you'd be willing to contribute it.

--David

From: specs-bounces <at> openid.net [mailto:specs-bounces <at> openid.net] On Behalf Of andy.dale <at> ootao.com
Sent: Wednesday, October 18, 2006 11:44 PM
To: Digital Identity Exchange
Cc: Digital Identity Exchange; specs <at> openid.net; general <at> openid.net
Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport

I'd be interested to hear if people think the ph-off plugin is useful or not.... If not why not?

If people think it's useful then I will happily extend it and make it more usable and I will put it into whatever open source project would like to house it.

I built it as a proof of concept that it _could_ be done... Now the question of _should_ it be done

http://chile.ootao.com/phoff/

Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale
http://xri.net/=andy.dale

***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and buy one:

http://www.ezibroker.net/partners.html

***************************************************************************

Chris Drake <christopher <at> pobox.com>

10/18/2006 07:20 PM

 Please respond toDigital Identity Exchange ietf.org>

 To Scott Kveton janrain.com> cc specs openid.net, general openid.net, Mike Glover janrain.com>, Digital Identity Exchange ietf.org> Subject Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support

Hi Scott,

All solutions for client-based MITM and phishing prevention can easily
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.

We can then leave these people to build their tools and protection
howsoever they like, safe in the knowledge that when it's *done*,
there will be a range of new plugins that will immediately work with
all OpenID 2.0 enabled sites - and best of all - it does not have to
hold up the OpenID 2.0 development in the meantime.

The only thing we need to give to these tools is a way to get the
plugin needs to be able to get an entry point for the OpenID CGI code
on the web site.

-----------

Here is a copy of my vote to include the above proposal, which

Hi,

Why's this proposal "depreciated" ?
( http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my vote here:

+1 to [PROPOSAL] bare response / bare request

Besides the listed uses, it also allows IdPs to layer privacy and
delegation easily on top of OpenID, as well as permitting cool future
features (like letting a user change something at their IdP, and have
that change be "pushed out" to all relevant RPs).

This is a small and simple to implement "hook" which I believe will be
the dominating bit of OpenID protocol use in future.

Alternatively - if we can standardize a way for the OpenIDHTTPAuth
proposed extension to discover the RP's OpenID "entry point" [so as to
reliably eliminate the "optional" first step proposed here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good
working alterative way to accommodate the "bare response" part that we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL
that's somehow available to scripts, plugins,
software agents that encounter OpenID login
pages.

-----------

Kind Regards,
Chris Drake

Thursday, October 19, 2006, 6:07:08 AM:

>> It is vulnerable to a man in the middle attack - the RP, instead of
>> redirecting to the IdP redirects to itself or some other site in
>> cahoots, then proxies the conversation between the user and the IdP
>> thereby compromising the users (global) credentials as they pass through.

SK> be a particularly easy solution to it and I classify this as one of those
SK> "The Internet Sucks" problems.  I'm not saying we shouldn't/couldn't do
SK> anything about it I just think the right solution that mixes
SK> ease-of-implementation and user need hasn't been found yet.

>> There really needs to be user-agent support to avoid that - either
>> something CardSpace like, or browser plugin that only ever presents a
>> pre-authenticated user.

SK> I think we're headed in this direction.  However, we have to crawl before we
SK> can walk.  At least solving a big chunk of the use cases, getting some
SK> momentum behind the platform and solving a specific problem for users
SK> *today* is better than trying to build the perfect tool.  We can talk and
SK> talk on these lists but we really don't know how users are going to use this
SK> stuff (or abuse it for that matter) until its out there and working in the
SK> wild.

SK> I can't emphasize more the fact that with every passing day that we don't
SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific
SK> user problems that are solved in the existing specification.

SK> - Scott

SK> _______________________________________________
SK> general mailing list
SK> general <at> openid.net
SK> http://openid.net/mailman/listinfo/general

_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix

```_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
```
12 Sep 2006 02:57

### What's up with DIX?

```Hello Everyone

Market demand for an identity protocol now has led Sxip Identity to
merge the Digital Identity Exchange (DIX) draft work into OpenID 2.0.
http://openid.net/

I'd like to thank everyone that contributed to the DIX discussion and
invite you to join the OpenID 2.0 discussion.
http://openid.net/mailman/listinfo/specs

From the WAE BOF there were people interested in working on EKR1, EKR2,
EKR4 and then another group (including myself) that are primarily
interested in EKR3, which is more narrowly defined then the DIX charter.

I'd like to invite everyone interested in EKR3 to join Web Attribute
eXchange WAX which would reference OpenID 2.0 as starting point to
see if there is interest in a BOF at the next IETF.
https://www1.ietf.org/mailman/listinfo/wax

I will repost this email in a week in case people miss it.

-- Dick
```
21 Aug 2006 17:33

### dix & ietf-http-auth

```All,

These two lists above are very similar in terms of their charter - not
identical, but similar enough.  I am concerned that the conversation
about solutions in this space could be too fragmented.  I'd like to
propose that we combine lists.

Eliot
```
10 Aug 2006 03:05

### RE: Re: Dix & OpenId?

```Ah, glad the meeting was mentioned here as well.  Sorry I forgot about
that.

Tomorrow I'll be hosting another OpenID get together along with JanRain
and Sxip.  It will start at 10am and run through the afternoon when
we'll then migrate to the OpenID 2.0 event hosted by Dabble that evening
in Berkeley (http://www.kaliyasblogs.net/Iwoman/?p=401).  Agenda is
mainly focused around solidifying the Authentication spec and it should
be a good day of discussion like last time.

Address is 675 E Middlefield Road in Mountain View; look for building
five on the VeriSign campus.  Please just shoot me an email letting me
know if you're going to join us.  Hope to see you there!

--David

-----Original Message-----
From: Dick Hardt [mailto:dick <at> sxip.com]
Sent: Wednesday, August 09, 2006 7:52 AM
To: David Fuelling
Cc: 'Digital Identity Exchange'
Subject: [dix] Re: Dix & OpenId?

On 9-Aug-06, at 7:14 AM, David Fuelling wrote:
> The OpenId 2.0 draft spec has many similar components to the DIX draft

> 1 (pre-saml) spec.  In addition, it looks like Sxip Identity is a
> founding sponsor of the OpenId bounty program, which seems a bit
> counter-intuitive to me (although I can see the motivation of wanting
> to publicize Identity 2.0 in general).  Regardless, Sxip Identity has
> based Sxip 2.0 on dix, and has been a major backer of dix.
Hi David

The timing of your question is impeccable!

The Sxip people are working with incorporating much of DIX into OpenID
2.0. There have been a number of backroom conversations going on
(mostly with the folks at JanRain and David Recordon of VeriSign) and
there is a meeting at VeriSign's Mountain View offices tomorrow if
anyone on this list is interested in attending.

Converging the protocols seems to make the most sense (features from
each were being incorporated in the other anyway)

-- Dick

_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix
```
9 Aug 2006 16:14

### Dix & OpenId?

Hey Everyone!

I’m wondering if people could enlighten me about OpenId and how it will relate to the Dix protocol, and Identity 2.0 in general, in the near future.

The OpenId 2.0 draft spec has many similar components to the DIX draft 1 (pre-saml) spec.  In addition, it looks like Sxip Identity is a founding sponsor of the OpenId bounty program, which seems a bit counter-intuitive to me (although I can see the motivation of wanting to publicize Identity 2.0 in general).  Regardless, Sxip Identity has based Sxip 2.0 on dix, and has been a major backer of dix.

So, I’m wondering how people (especially the Sxip people on this list) see Dix moving forward.  Are there plans to join OpenId 2.0 and the DIX protocol?  What kinds of discussions are taking place between the Dix and OpenId 2.0 folks?

The reason I ask is that I’m planning to incorporate Dix into my Open Source project.  However, with the OpenId bounty program, it seems like I may want to consider OpenId instead, especially if Sxip is going to back OpenId.  Where will we be in 5 months?  Should I stick with Dix??

Thanks for your thoughts, speculations, and ideas!

David

```_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix
```
18 Jul 2006 20:07

### the point of a standards process

The point of a standards process is not what you put into the spec, its what you leave out.

Well said!

Joaquin

(And certainly true.  It has to be understood, of course.  Example: A bolt standard lists many combinations of diameter and thread pitch.  Many.  But a vanishingly small percentage of the possible combinations, almost all of which are left out of that standard.

(In our business, a very effective way to ensure there is   n o t  interoperability is to provide many options.)

```_______________________________________________
dix mailing list
dix <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dix
```
15 Jul 2006 19:38

### DRAFT: WAE BOF minutes

```The meeting started off with the usual agenda review. Agenda was
accepted as proposed.

The first item was Terminology.
Internet Security Glossary
http://www.ietf.org/rfc/rfc2828.txt
Other Glossaries mentioned:
Internet Security Glossary, Version 2
http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt

SAMLv2: Glossary
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

"identity gang" lexicon
http://identitygang.org/Lexicon

The next item was Problems we want to solve (see agenda)
- whitelisting
- claim minimality
- proof of server identity

Sam Hartman made his presentation, there were a few questions.

There was then discussion on Problems we want to solve.
****** edit here -- right title? same as before

non-browsing HTTP support
support for existing infrastructure
Cross Application Credential (XAC)

Grouping of problems was then started.
Dick Hardt's slide was presented.

Ekr proposed grouping the problem up as:

EKR1: fix http auth
- anti-phishing

EKR2: cross-site identity, Eliot's dad, SSO

EKR3: Claim & Attribute Transferral

More detailed discussion on each problem then ensued:

EKR1: Fix HTTP Auth
AD questions to audience concluded with:
- Liaise w/ W3C on GUI
- Liaise w/ APWG
- Layer / Arch TBD
- can stand alone, but coordinate w/ EKR2 and EKR3
EKR1 does not require EKR2

EKR2: cross-site identifier
(Eliot's dad problem was broken off to be EKR4)
- raw assertions of identity are easier to trust than attributes
- name subordination
- existing technology, but glue work
Question: Is there glue work to be done by the IETF?
- no one thinks there is no glue work, 15 think there is, 15 are
not sure
12 ok on work if EKR1 not happening,

EKR3:Claim & Attribute Transferral
- existing claims and syntaxes may be used
- binds attribute assertions to underlying communication
- not limited to HTTP
Question: Is there glue work to be done here by the IETF?
12 support, a couple object

EKR4:
part of EKR1 & EKR 2

Discussion if EKR1 and EKR2 required different BOFs at next IETF
meeting. Clearly different drafts would be required. Best to combine
group working on them.

Meeting concluded 15 minutes late.
```
14 Jul 2006 16:34

### Extant Applicable Security Glossaries

```Here's pointers to hopefully useful glossaries...

HTH,

JeffH
-----

Internet Security Glossary
http://www.ietf.org/rfc/rfc2828.txt

Internet Security Glossary, Version 2
http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt

SAMLv2: Glossary
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

Liberty Technical Glossary v2-05
http://www.projectliberty.org/specs/draft-liberty-glossary-v2.0-05.pdf

Note that all of the above have extensive references to the work they are built
upon. Also note that the SAMLv2 and Liberty glossaries are examples of going
through the exercise of "profiling"/"reusing" existing terminology for use
within a particular context, SAMLv2 being particularly relevant to the WAE
discussion.

Also worthwhile to point out is Lynn Wheeler's overall glossary, which composes
the widest collection of extant glossaries that I know of, so it is
particularly useful for figuring out how various constituencies are using any
particular term (or whether they are using it at all)

http://www.garlic.com/~lynn/secure.htm

Note that the references for Lynn's sec gloss are listed on the page "above"
the gloss...

http://www.garlic.com/~lynn/

---
end
```
14 Jul 2006 02:43

### More requirements

```On the plane to IETF I realised that there were several more potential
requirements to add to ekr's list:

The user should be able to visit the same site multiple times without
the site being able to tell that it is the same user, even if the user
is, for example, asserting the same external claims each time. This
protects the user's privacy. Obviously if data provided by the user is
unique to that user (for example, age and address combined are often
sufficient to uniquely identify a person) then no amount of cleverness
can provide SSU, but SSU should be available to the extent permitted
by the uniqueness of the data provided.

The user should be able to visit multiple sites without the sites
being able to collude to correlate the data provided by the user. This
is a weaker requirement than SSU (that is, MSU does not guarantee
SSU). Again, this protects the user's privacy.

14. Attack Resistant Credentials (ARC)
Credentials should be such that the (computationally limited) verifier
cannot reconstruct the original credential by brute force. Note that
the impossibility of this may rely on the user choosing strong
secrets, which is often unlikely, for example where the sole source of