(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 protected] https://www1.ietf.org/mailman/listinfo/dix
