<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr><FONT face=Arial size=2>"3. Im GUESSING that cliamid receive my email address from myopenid using openid auth/sreg/AX during session translation (classically, from IDP to SP), and can thus from the 2 data claims (sreg.email and openid.claimedID) supplied over that OpenID Association now compute the microid and verify it agrees with that on the referecned "identity page"."</FONT></DIV></BLOCKQUOTE>
<DIV id=idOWAReplyText15227 dir=ltr>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I've been reading the writings of Fred Stutzman and Will Norris on the topic of the "system" within which MicroIDs are intended to operate, particular in the context of OpenID. Nothing of what I write-up below is authoritative, being my own assumptions about the workings of the system, gleaned from their writings. But, absent a coherent description of the system of OpenID reputation management, all I can do make my own purported description from the meager facts that exist!</DIV>
<DIV dir=ltr> </DIV>
<OL dir=ltr>
<LI>
<DIV>We know that Users on blogsites exploit login session to make statements, including reputation statements about other entities. That blogsite may auto-attach a MicroID to any such statement, thereby asserting original authorship of that statement by a known (and verified) subscriber of the service. In doing so, a blogsite operator knowingly makes a statement about a statement, of course, intending others to rely upon it. The only reason for this reification to have microID form is, apparently, to exploit what MicroIDs are all about: (i) obfuscate the subscriber-selected "author's communication id string" (to address blitz-spamming), and, (ii) exploit the one-way function property of SHA-1 to bind multiple statement. <BR></DIV>
<LI>
<DIV>Now, we can note that MicroIDs issued in this manner have an operational context: the session manager of the blogroll operator. By controlling login sessions, a resulting security context comes into being which addresses the risk of unauthorized parties falsely binding their own or others' claims of authorship to original statements that are infact made on the provider's site by a legitimate (and authorized) subscriber. If the resource URL denoting the original statement has https form and bears in its query string the fingerprint of the SSL cert used during statement posting by the author, one might enable some SSL context from the original posting session to also be indirectly bound into the MicroID. Similarly, if the communication identifier used in computing the MicroID is an OpenID ClaimedID, the #fragment component of said value might similarly be indirectly bound into the MicroID, addressing re-issued OpenID URLs. XRIs values, HXRI SSL certs, SAML assertions and XRD LocalIDs play similarly into further variants, exploiting XRI2 resolution.<BR></DIV>
<LI>
<DIV>In the web2.0 world, we can expect original statements (including reputation assertions) to be made by a given party on many sites. Some of those sites or particular pages thereof will be subject to mashup by third parties, acting for the author, those granted citation permission by the author, or others acting without the author's explicit grant of permission to cite, excerpt, perform an act of reliance or make a using. Notwithstanding permission, in all such cases, we may assume that the author's communication identifier may be common on all those sites publishing the author's original statements, where such value acts as a common foreign key - with all the usual linking properties defined by the classical relational calculus for shared foreign keys.<BR></DIV>
<LI>
<DIV>One simple mashup site is a listing service focusing on authoritative citations, such as that operated by ClaimID. Acting for authors at their behest, it lists an author's original statements, denoted by URL reference to the page or page element of some document distributed via the publisher's website. ClaimID apparently act in a constrained manner subject to a disclosed policy, only listing statement together under an author's name once the service has "verified" that all the MicroID-based claims of authorship "align" (applying a chosen foreign key).<BR></DIV>
<LI>
<DIV>OpenID has been little involved in the system description so far. However, the value of this claim issuance and verification system seems set to exploit OpenID in two ways. First, as reliance on an OpenID during login implies the OpenID Consumer "accepts: that the user controls at least one communication identifier (the OpenID URL/XRI itself), the act of subscribing and then using the ClaimID services after login with a given OpenID can be seen as inviting ClaimID now list authorship claims bound to that OpenID. Second, rather than the OpenID used during login serving as the Communication identifier, some or other attribute obtained from the positive OpenID Assertion may serve as an alternative, foreign key (e.g. the users email address/URI)<BR></DIV>
<LI>
<DIV>In either case, the ClaimID consumer may require OpenID technology be used to establish a session ...that invites the act of (re)listing authorship claims. If this consuming party, acting now as a MicroID verifier, establishes a policy that the publishers must also use OpenID, this set of properties defines a community of interest; of which there would seem to be several types. One major type can easily be defined, by considering the common property shared by the publishers and the verifier: they are all infact OpenID consumers, where any given user's OpenID URL/XRI is commonly regarded as the Communication Identifier. A minor variant of this type obviously defines a sub-community - whose members not only rely on OpenID technology for session management but who all furthermore use some particular attribute (e.g. email) as the communication identifier when they issue or verify MicroIDs. A second major type refines the first focusing on the notion of verification policy. Here, an operator such as ClaimID act only verifies the MicroIDs of those publisher-issuers who use a certain group of OPs when consuming OpenIDs As with the first type, a minor policy-based variant of this second type exists, requiring that all publishers enforce individual accountability through session management. This entails that the verifier may indirectly rely on the publishers to ensure that only a subscriber controlling the blog account can (indirectly) bind MicroIDs to their original statements.<BR></DIV>
<LI>
<DIV>The system seems to come full circle when a blog site operator addresses the act of "accepting" comments on a given author's blog entry (making some statement or other), as left by users signing in to the comment function using OpenIDs. If configured to do so, one can imagine the operator first consulting the list of "reputable OPs" so designated by the author, as listed on ClaimID. Only if the OP of the commentator can be determined to be on the list, will the comment be accepted. Given MicroID allows communities of interest to impose any semantics they desire on the resource URL used in computing a MicroID, the form of the URI may invoke a reputation/authorization algebra, such as a partial order. By enforcing the partial order, the site may act as a policy decision point, executing authorization policy of the user represented by the author's policy enforcement point: his/her ClaimID listing.</DIV></LI></OL>
<DIV dir=ltr>If I look back at that (purported) system description, it seems scalable, it seems to fit the web model, it uses classical security engineering terminology (authN.sessions, authZ, PDP, PEP) and seems to allow for all sorts of policies by any party engaged in the act of "listing" reputation statements. It works just as well for XRIs, as http(s) URLs and their HXRIs variants. Nicely, the system is self-applying, since anyone can issue a reputation statement on those such as ClaimID who engage in making _listings_ of others' reputation statements.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>What I have no confidence in is that the above system description or variants are received wisdom, are community endorsed, are commonly understood, are part of the mission, or are an accurate rendition of where folks are generally going in their OpenID rollouts.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Is this kind of stuff discussed anywhere?</DIV></DIV></BODY></HTML>