Subject: [dix] Five paths for the six propositions of the "DIX Service"?

From: Nick Ragouzis <[email-masked]>
Date: Fri, 27 Jan 2006 13:32:12 -0800

(Note that in the following I am only assuming the submitted 
I-D is intended only as an exemplar and descriptive of the use 
cases (i.e., the productions of such cases); not more than that. 
It is at the charter this note is directed.)

Comments I've received on the discussion of lightness (or not) 
of just one pre-existing identity-domain protocol really just 
point me to an underlying problem in the proposed charter and 
the I-D: when defense about the fitness of a protocol on one 
dimension (identity token) is carried forward principally by 
advancing the *other* merits of that protocol (web page editing), 
then that protocol has likely wound together too many goals.
A similar dynamic has played out on the list. That's prompted 
me to take another look at the discussion abt the charter, 
and the I-D.

I find the "DIX protocol" of the I-D to be a combination of
protocols (in a most general meaning) at various levels and to
various ends. As such it is more the "DIX Service", a vertically-
integrated system (here using DIX less as a meaningful acronym
but more, merely, as a label). Maybe that's just me, just waking
up (or being excused from jury duty). I think that design and 
adoption of such vertically-integrated systems have some well 
known characteristics, but ease of specification for wide 
interoperability and future proofing (and actual implementation 
of such interoperability) isn't one of them. 

This just reinforces that the proposed work would unfold in the 
context of several component protocols already designed for 
composing, extensibility, and profiling. Or at least we've not
found the specific gap where such composing, extension, and
profiling couldn't be brought to bear. 

The overall context is for some version/profile of operations of 
this service to be possible to realize with as little as possible 
effort over that required for slightly-enlightened web site 
operators and web site authors, for working with clued-in web 
site users. The presumption is that HTTP protocols handled by 
common HTTP servers working with ordinary HTML presentations of 
data. This presumption extends to nothing more than, say, such 
users following simple-if-a-bit-mysterious ordinary copy-paste 
of "magic potions" with some substitutions in templates. The
expectation is, however, that even with this simplified service,
most of the services (the protections, the additional
capabilities) would be automated through, say, scripting
facilities of the related service providers and installed web
products and environments.

Although that's the baseline, it's not necessarily the full 
extent. These are only presumptions, not prescriptive or 
limiting, at this point. We'd want many other services to
be able to adopt parts, right?

The next thing to notice is something a bit extraordinary:
the user interface, and the expression in a user agent 
presentation language, is integral to the proposition. To me 
it seems by comparison enlarged to the level of a separate 
component of the service.

>From there I suggest we are considering several propositions:

1. There is a "digital identity user form factor expression 
   markup language", which describes how components of digital 
   identities may be marked and handled in html page forms 
   intended for human consumption (but not excluding automation). 

2. There is a "digital identity authority cookie protocol", which
   can hold user preferences regarding authorities. This could
   not be called a discovery service as it would describe nothing
   more than description and publication (or redirection of
   same) of said preferences using the simple known-location 
   registration (UA) and simple table lookup of cookie handling.

3. There is a "digital identity authority services description
   and discovery protocol" authorities to use to describe 
   their supported identity operations with respect to the
   particular identity, including one (presumably more) ways 
   to publish this, and to re-vector requests it receives to 
   other authorities of similar information according to user
   and service desires.

4. There is a protocol for relying parties to describe 
   requirements for, and to request statements about, claims.

5. There are the related security protocols.

6. And some seem to be entertaining the need to propose a
   restriction or characterization of some type on the
   structure, syntax and meaning of identifiers and digital 
   identifier.

Notwithstanding the above, at the outset of our work there is
no presumption of one identifier format, or one token format, 
or one request/response language, MEP, or transport. As dialog 
has proceeded on the charter, however, we see how the range and 
intermixing of the above propositions make very difficult the 
questions of required implementations and selections of use 
cases.

My suggestion is that we work towards agreement on (or discard) 
a few items:

First: Proposition #1 is a useful piece of work, and could happen 
  with the intention of being compatible across a selection of
  other lower/parallel protocols (of which we could pick the
  initial set). It could be implemented and such implementations
  deployed separate and apart, or exclusive, of the realizations 
  of the other propositions.  

Second: Proposition #2 is also a useful piece of work, with broad 
  applicability, but defined separate from proposition #1 (and the
  others). It too could be implemented and deployed separate and 
  apart from the other propositions.

Third: Proposition #3 is certainly useful, and likely a 
  significant separate piece of work. For one it would benefit
  from making a creditable effort at characterization and gap
  analysis of other pre-existing protocols and work in progress. 
  The ultimate outcome would, then, be a generalized method for 
  serialization and transformation, with the probably addition 
  of metadata.

Fourth: Proposition #4 and #5 are areas where significant pre-
  existing work exists, and that work is highly susceptible to
  composition, extension, and profiling. Further work is
  necessary by this/some community, and then a community (perhaps
  in those bodies, perhaps here) can describe the related
  compositions/extensions/profiles. A possible outcome is a
  new capability, but one that also (simultaneously) 
  demonstrates its potential for interoperation with the other 
  work.

  BTW: A finding of a gap in _clarity_ of these pre-existing 
  component protocols isn't an argument for building another 
  protocol. It, OTOH, argues for work on clarity on those 
  protocols ... from which all would benefit. Realistically, a 
  large number of the same people (and especially a large number
  of the key architects) who've worked on those protocols will 
  work (and vote) here, and those new to those protocols can, 
  here, bring valued perspectives for their improvement, in 
  clarity and in extensions and profiles. 

Fifth: Proposition #6 should be out of scope for this work, 
  avoiding attempts at a narrowed or limited definition. More 
  specifically, the test should be that every proposal for work 
  (e.g., on Propositions 1-5) should support at least the known
  identifiers, more ideally the expected identifiers. An
  approach would be: presumption of support; or a specific
  description for why support is omitted in the face of 
  overwhelming difficulties. Restriction or removal of particular 
  identifiers or a particular concept of digital identity should 
  require more than some undifferentiated ideal of simplicity or 
  lightness, otherwise we do not advance interoperability nor 
  do we prepare for the future ... neither of which makes user's 
  lives easier.

I'd just like to mention that I propose this intending that if it 
has any merit it would be modified until we can see that all the 
goals, including the search for simplicity, are still achievable. 

Thanks,
--Nick

BTW, on that theme of existing work, I think we should endeavor 
to use existing glossaries, or to create new definitions as 
derived through extension and modification of the several pre-
existing glossaries on the matter (not the least the IETF 
contributions).  Unfortunately this weight falls to the writers 
and editors, as few readers of the list will actually bother to 
write at length about every stray term (with the usual Pareto 
effect of a few generating a LOT of noise). Perhaps its a work 
item to designate authoritative glossaries, and a procedure for 
extending them with local additions or variants. In the least,
then, folks would know which glossaries to read. :-)

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