<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Chris,</div><div><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica"></font></p></blockquote><br><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">This is where Portable Contacts comes in, since we already accommodate</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">sending other known identifiers for a person.</font></p></blockquote><div><br></div><div>Just looking at the draft spec for the first time now, it's looks like a pretty large and structured data set. I see no reason the same information couldn't be conveyed using AX as a sort of transport layer, at first glance. I think the SREG/AX duplication is counterproductive. SREG uses its own namespaces, but PoCo seems to use its own protocol, which is a more significant divergence.</div><div><br></div><div>Is there a strong reason not to see all this data as attributes? It seems easier to just treat these sets of information as standard object classes to be populated appropriately and transported using existing mechanisms. That would be better for implementers and reduce confusion by deployers, increasing the chance they could implement privacy controls, for example.</div><div><br></div><div>And one more bit of consolidation: is there a place where I can track all the specs this community is generating?</div><div><br></div><blockquote type="cite"> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">I can't say whether it's wise to separate OpenID identifiers from</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">others, though, and I also don't know how well RPs will trust data</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">provided either via AX or PoCo (i.e. if a list of OpenIDs is provided,</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">will/should an RP take for granted that the list is a valid list of</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">verified identifiers?).</font></p> </blockquote></div><br><div>I think it's good to flag an identifier's type, in case the RP wants to make further use of it, e.g. additional queries.</div><div><br></div><div>Trusting attributes is a separate problem which requires a trust model. There are handshakes, federations, reputations, hierarchies, and more. I'd love to see these protocols transport information about trust.</div><div><br></div><div>I think TX is going in the right general direction, and I applaud the brainstorming that went into it. However, it seems to be weakly bound to the authentication event and attributes. The use of a nonce might refer to overloading the nonce used in the initial authentication event, but the draft isn't clear. It probably wouldn't work for non-repudiation or integrity protection of attributes, for example, because the attributes, identifier, etc. are never signed and are very loosely bound.</div><div><br></div><div>Maybe it's time to begin cobbling these things together into something less organic.</div><div><br></div><div>Thanks for your ideas,</div><div>Nate.</div></body></html>