tag:blogger.com,1999:blog-117418712024-03-21T17:38:22.548-07:00The Tao of XDI=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.comBlogger118125tag:blogger.com,1999:blog-11741871.post-28952837514026352512019-06-06T19:53:00.002-07:002019-06-06T20:00:03.310-07:00Introducing PURDAH<br class="Apple-interchange-newline" />
<br /><br />So I'm reading Neal Stephenson's latest novel 'Fall'... In Chapter 11 he introduces PURDAH... Personal Unseperable Registered Designator for Anonymous Holography. <br /><br /><br /> He explains that Holography is from the original meaning of the term:<br /><blockquote class="tr_bq">
<br />"A holograph is a document written entirely in the handwriting of the person whose <a href="https://en.wikipedia.org/wiki/Signature">signature</a> it bears. Some countries (e.g., France) or local jurisdictions within certain countries (e.g., some U.S. states) give legal standing to specific types of holographic documents, generally waiving requirements that they be witnessed. One of the most important types of such documents are <a href="https://en.wikipedia.org/wiki/Holographic_will">holographic last wills</a>." - <a href="https://en.wikipedia.org/wiki/Holograph">https://en.wikipedia.org/wiki/Holograph</a></blockquote>
<br />"So it's just an anonymous ID, with a fancy name?", Corvallis asks...<br /><br />No, PURDAHs are all registered in distributed ledger technology so their veracity can be verified at any time. Unseperable means that no one can take it away from you, as long as you take reasonable precautions...<br /><br />At least Neal seems to be paying attention!=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-62372220349391901732017-11-08T16:08:00.003-08:002017-11-08T16:11:01.905-08:00Trust vs ConfidenceOver the years, in my own mind, I have built specific semantics around the terms 'Trust' and 'Confidence'. These are closely related to the validity of 'Proof'... I think that often the use of these terms in the vernacular are too fuzzy to be of use in identity system discussions. I would posit:<br />
<br />
<h4>
Trust:</h4>
Security and its many mechanisms are used to establish trust; once trust is established, you just trust. My canonical use-case for this is access to the school blog. I can grant or revoke write access to my kids' school blog. I give access to people who I trust will only post age appropriate material. I could use manual or automated mechanisms to check posts before they are published but the effort or cost outweighs the risks. I choose to trust. Trust is a human, emotional, social construct that implies a loosening of control. Trust can be abused and it is, knowing the risks, the rewards and the remediations for abuse of trust is important (systems of accountability; reputation? legal?). So trust needs to be bounded "I trust XX to do YY".<br />
<br />
Concretely: I trust an entity with my money, like coinbase, who has my bitcoin wallet. I have taken a leap. Coinbase could steal my money despite all of the controls of the blockchain and distributed ledger technology. I could use a different wallet technology but then I am still choosing to trust the software that enables that wallet, or the hardware that the software runs on. At some point the cost of not trusting outweighs the risk and the expense of trusting.<br />
<br />
So on some level... this poses the question: If my relationship with coinbase is purely one of trust that they will hold my money and return it based on the current value of bitcoin, what difference does the underlying blockchain technology actually make to me? I could use bitcoin in a way that I don't need a trusted third party (at the extreme: build my own hardware and software) but I don't, and most people don't.<br />
<br />
I think it is incumbent on people talking about identity systems to really understand where security ends and trust starts. Do most people understand how misplaced their trust in their mobile hardware could be?<br />
<br />
So to me Trust is what happens beyond the bounds of control. Or to put it another way; Trust is what happens within 'pipes' or 'bubbles' of control established using security mechanisms. <br />
<br />
<h4>
Confidence:</h4>
Confidence is, when I'm trying to use it precisely, a measure of certainty in a claim. In terms of an identity system a claim might be:<br />
<br />
<ul>
<li>an authentication claim (I am the person identified by ID XX) </li>
<li>an authorization claim (I should have access to this resource)</li>
<li>an attribute claim (I am over 18 years of age)</li>
</ul>
These claims often get delivered in terms of or together with 'Proofs'. Where 'Proof' is a mechanism (hopefully standardized) to deliver a claim with metadata to increase confidence (in the absence of trust). Some examples:<br />
<br />
<blockquote class="tr_bq">
In an authentication claim, the claim of the ID may be accompanied with claims of who established the ID (signed by a private key of a trusted party) the claim may also include details of how the user was authenticated (password, multi-factor, smart card, etc...). The associated metadata establishes a level of confidence in the claim. Step-up authentication models (you can view your balance if you logged in with a password but you have to use multi-factor to initiate a transfer) are a direct result of your levels of confidence in various authentication claims. </blockquote>
<blockquote class="tr_bq">
In an attributes claim again one would expect the claim to be signed by a trusted party, trusted to make the specific claim, and the claim may include metadata about how the attribute was validated. An over 18 years of age claim that was self asserted (they checked a checkbox that says "i'm over 18") may be enough to satisfy <a href="http://searchcrm.techtarget.com/definition/COPPA" target="_blank">COPPA</a> compliance requirements in the US but would be insufficient to provide legal access to porn in the UK. </blockquote>
<h4>
Bringing Confidence and Trust together:</h4>
So with a claim that is signed by a party that is trusted to make age claims; the signature gives me confidence that claim is from the the trusted party and then I trust the age claim rarely do I require proof of the mechanics of acquiring the validation. Even if I require details of how the claim was was established (self asserted or credit system check) I could, but I don't, make the third party 'prove' it.<br />
<br />
That is establishing a Trust space using a security mechanism (in this case; PKI and standardized claim semantics) and then... trusting the information that is provided in that secured context.<br />
<br />
<h4>
Alternatively:</h4>
Is there is a source (glossary) that you use to define these fuzzy terms when you reference them in specs? I know that there were efforts to normalize identity terminology back in the day... did any survive the test of time? <br />
<br />=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-31129989668975784732017-11-01T10:07:00.001-07:002017-11-01T10:07:56.673-07:00Eight years and countingWell it was 8 years since I last posted here and 12 years since I started this blog and I have to ask... what has changed, what has been achieved in all that time? I've been out of touch with this space for a while and i'm going to go on a little personal voyage of discovery to see what I can learn and see if any of the fundamental problems have been solved.<br />
<br />
My first step is going to be attempting to articulate in abstract terms what I consider to be 'the fundamental problems'.<br />
<br />
My primary point of interest since this all started has been to give people access to and appropriate control over data about themselves and their transactions. It is well known that the likes of Google, Facebook, Experian, Equifax and many others make their money trading in data generated by or about us. These companies provide important and valuable services but they do not adequately respect individual privacy nor do they fairly include the individuals that are their currency in the value chain.<br />
<br />
I have spoken with business stakeholders in large organizations that use these services, despite knowing that they are 'unclean', because the value they add is very real. The increase of ROI on targeted marketing based on these services is phenomenal. As we, as a community, worked on alternate models they were eager: Gives us a viable alternative, they would say, and we will use it. As far as I can tell there is still no viable alternative... I will try to unpack why.<br />
<br />
I will try to discover if we have a technology problem, a communications problem, a legal problem, an education problem or a business problem; presumably we have a little of each.<br />
<br />
The lack of a viable alternative is closely related to scale. The aforementioned companies have huge user populations which is what makes them so appealing and so valuable. Users do not adopt a technology based on the elegance of the standards or even, unfortunately, based on the strength of the privacy. Users primarily adopt technology because it makes it easier for them to do something they want to do (including playing games and consuming porn). With that said I do believe that there is a growing number of people dissatisfied with the status quo. People who would be willing to engage in an alternative system even if it costs them a little. How do we provide them a viable alternative?<br />
<br />
So a fundamental question I have is: Do we have the building blocks to build a viable alternative and we just haven't found the right constellation of services and apps to provide or, are there still gaps in the technology stack to build a viable alternative? I hope to find out.<br />
<br />
In my upcoming posts I will start to dig into what I believe are the important qualities of systems that might address this need. I will undoubtedly build on old classics like Kim Cameron's <a href="https://msdn.microsoft.com/en-us/library/ms996456.aspx#lawsofiden_topic3" target="_blank">Laws of Identity</a> but will also add some flavor of my own in terms of business and legal frameworks that I believe need to be in place. I will also address the qualities that I believe are necessary for a distributed data network to actually work, at scale, as a data network (Spoiler: Link based systems like "<a href="http://www.infotoday.com/cilmag/nov15/Hastings--Linked-Data-in-Libraries.shtml" target="_blank">Linked Data</a>" work great for unstructured content, documents, but fail rapidly to satisfy operational requirements for structured data).<br />
<br />
I'm excited to dig in and learn blockchain and blockchain alternatives... Please let me know about stuff that you think is worth reviewing and including as stops on my voyage of discovery!=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-56351216321771496652009-08-24T09:27:00.001-07:002009-08-24T09:32:49.590-07:00SXSWIf you have a chance; check out this proposed session for SXSW:<a href="http://bit.ly/vuPu5">http://bit.ly/vuPu5</a>. Have you noticed that when you search the internet you probably don't see results from the stuff that you pay for (subscriptions, stuff available through your local library, etc...)? this panel will discuss how we could fix that... If you think that would be useful.. go give it the thumbs up.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-54569904675962871152009-07-20T07:24:00.000-07:002009-07-20T07:49:47.395-07:00AccountabilityI have written about reputation in the past and continue to evolve my thinking on the subject. I had an interesting interaction last weekend with <a href="http://epic.org/epic/staff/coney/">Lillie Coney</a> of <a href="http://epic.org/">EPIC </a>while on a panel together at <a href="http://www.ala.org/ala/conferencesevents/upcoming/annual/">ALA</a>. Lillie described the legal frameworks that exist to both protect and circumvent our privacy as a lawyer and a privacy expert she described the steps necessary to strengthen our privacy position in the law. I found myself pushing back on Lillie; expressing that Reputation systems are just as important as systems of accountability for privacy as legal frameworks. If we had more time I think we might have had an interesting discussion on the subject.<br /><br />Here's the summary I reached in my head: I do not deny that the legal system works to protect our privacy interests at certain levels. However, as an individual with a compaint against a large company I have very little recourse. For me to take action, personally, against a large corporation is prohibitavly time consuming and costly. I believe that robust reputation systems can help give me a way to have a voice.<br /><br />We know that there are places that the legal system works. We know that there are places that reputation systems work. There is a gap between these 2 places where very little works. Lille was explaining how we fill that gap with legal framework. I propose that we can also fill that gap with well constructed reputation systems. I don't think this is an either-or situation; together these things can provide robust protection and accountability that is available to everyone.<br /><br />My point is that while those of us who think about reputation recognize the importance of the legal frameworks, I'm not sure that the people who work on the legal frameworks recognize the importance of the reputation systems.<br /><br />What do you think?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com2tag:blogger.com,1999:blog-11741871.post-53613059006556733102009-06-12T10:07:00.000-07:002009-06-12T10:09:02.392-07:00Is anybody out thereIt's been a long time since I blogged :-( and even now I'm just asking a question...<br /><br />Now that I am actually implementing SAML stuff, specifically Shibboleth (mainly web sso). What book would you recommend I buy?<br /><br />THANKS=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-6206465350008199482009-03-03T07:48:00.001-08:002009-03-03T07:48:50.114-08:00What is SSOOne of the hottest issues in Identity Management is often referred to as SSO; Single Sign-On. However it is a horribly misunderstood and misused term. I will try to give a brief overview of what SSO is and isn't.<br /><br />What most people mean when they say SSO is the user experience of accessing multiple services and systems but only having to 'log-in' once. On the face of it SSO sounds great but there are some pitfalls that we have to be wary of. If we aren't very careful, the 'ease' of SSO is bought at the cost of privacy.<br /><br />The type of SSO that I am going to explore is the "HTTP Redirect" SSO mechanisms that are widely deployed for SSO on the web. This includes OpenID, Shibboleth (Web SSO), SAML (WebSSO), FaceBook, Yahoo! and Google, to name a few. These protocols differ in many details and have different strengths and weaknesses but they all share the same underlying HTTP Redirect mechanism. The basic pattern is this:<br /><br />1. Jane navigates to a web-site and she wants to log-in using a username and password that support SSO.<br />2. Jane clicks on the 'login' button on the page.<br />3. Jane has to tell the web-site who her SSO service provider is. This is known as the Where Are You From problem, otherwise known as WAYF. More about WAYF in a moment.<br />4. Once Jane has told the web-site who her SSO service is; a HTTP Redirect is sent to the browser to send Jane off to her SSO service.<br />5. At her SSO service Jane is asked to provide her UserName and Password.<br />6. If Jane convinces the SSO service that she is, in fact, Jane, then she is returned (via HTTP Redirect) to the original web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"<br />7. The web-site and SSO service communicate in such a way that the web-site can validate that this is really SSO service XYZ talking AND if it knows and trusts service XYZ it can go ahead and accept that this is Jane.<br />At this point we have performed 3rdParty Authentication or Federated Sign-On NOT SSO.<br /><br />8. Having done what she came to do Jane now navigates to another web-site.<br />9. When Jane arrives at the second web-site she is NOT recognized as being logged in. This site has no knowledge who she is or that she has logged in somewhere else before. If Jane wants to access 'protected' resources at this web-site she is going to have to click on the log-in button.<br />10. Again Jane will be asked Where Are You From and she will select her SSO service provider.<br />11. The web-site will then send Jane off to her SSO provider asking... "Who is this?"<br />12. Because Jane logged into her SSO service just a few minutes earlier the SSO service doesn't ask Jane for a UserName and Password this time, it immediately returns back to the web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"<br />13. The using the same trust validation as above the web-site can now believe that this is Jane<br /><br />And Jane only logged in ONCE... that is SSO.<br /><br />Jane still had to click on login twice and still had to provide her SSO service twice but she only Signed-On a Single time.<br /><br />There are variations in this flow, OpenID nicely shortcuts the double SSO service provider selection BUT you have to type in your UserName twice.<br /><br />The most common expectation of SSO that is not satisfied by the flow described is "why didn't the second site just 'know' that I had already logged in and who I was?" Apart from the fact that would be technically difficult the answer is actually that REALLY you wouldn't want that behavior... Once I explain why:<br /><br />If SSO worked that way, when you logged in once, everywhere you went on the internet would know who you are. Not just an IP address, they would be getting a message "here's Jane". All of the web-sites on the web could talk to each other and work out EXACTLY which sites you visited and which ones you didn't. That is generally considered to be a terrible breach of privacy. In order to avoid this privacy leak clicking 'login' remains an explicit action that the user must take. The action no longer means: "I want to enter my username and password" but now means "I'm OK telling this site who I am."<br /><br />There are ways for 'closely connected' sites to shortcut this experience. Handing a user from their Local Library System to the Consortia Meta-Search interface; a handoff that is between trusted parties; Janes identity CAN be passed from one service to the other providing the 'seamless' SSO that we would love to have. But you can't be sure that Jane was OK being identified at the second system unless you make the action explicit. As a service provider you have to make very careful choices between seamless SSO and user privacy.<br /><br />Rather than going on now:- You can tune in later for "SSO using Pair-Wise Identifiers to protect your privacy", "How and Why OpenID is different from Shibboleth Web SSO" , "Why you MUST trust your SSO service provider because they know a lot about you"...<br /><br />Please ask questions if I haven't been clear... Please let me know if you think I have said something misleading or wrong... I'm just trying to start a conversation here.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-48714571574191015222009-02-10T09:59:00.000-08:002009-02-10T10:07:51.944-08:00IDM 101I am now blogging at http://worldcat.org/devnet/blog/ I am going to be posting a series of posts that introduce basic Distributed Identity Management concepts, as I understand them. <br /><br />I can't decide if I should double post those posts here as well:<br /><br />reason to post here..<br /><br />although it is all basic stuff I am interested how much my understanding and articulation of the basics aligns with your understanding.<br /><br />reasons not to post here..<br /><br />if you want to read the stuff over there... you can just get that feed too.<br /><br />What should I do?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-56890416800039825862009-01-26T09:21:00.000-08:002009-01-26T09:31:55.591-08:00What's in a claim?The use of infocards does not dictate a specific authorization pattern. There are at least 3 authentication patterns at play that I can see... Identification, Roles based and Claims based... We can, and do, use all three of these interchangeably and simultaneously. I will explain what I think these three patterns are:<br /><br />Identification:- Provide a previously know ID that relying party can resolve to a user record that has all of the additional information needed to make permission decisions. In this case only one claim is ever needed... the ID as one assumes that ALL other information is in the user record. The major problem with this pattern is that sharing the same ID between different relying parties is often impractical and definitely bad from a privacy standpoint. Using pair-wise PPIDs does not really satisfy the Identification pattern as all you are enabling is the ability to say "this is the same person as logged in as before" but not get a lock on a user record (unless you do a mapping at each RP which is probably the BEST application of this pattern).<br /><br />Roles Based:- (See: http://en.wikipedia.org/wiki/Role-based_access_control ). With Role Based Access Control (RBAC) you don't need to know who the 'Subject' is; you trust the IDP to enforce policy and assign the roles and the RP simply has to present the functionality and access based on the roles provided. The major, known, problem with classic RBAC is that it fails to address either resource or person specific access control. There is lots written about this failing so I will refrain from going into details :-). <br /><br />Claims Based:- With this pattern all of the information that is needed for the RP to enforce policy is presented to the RP by the IDP. This includes not only the claim values but how the claim was established. Sometimes knowing that the IDP is willing to assert something to be true is enough to trust it, at other times you want to know that the 'Over 13 years old' claim was based on a more rigorous check than... "they checked a box that they are over 13". Claims based authorization becomes especially powerful, IMO, when you take claims from multiple claims providers so that you can do uniquely specific authorization and service delivery at each RP based on a Claims Network. <br /><br />Classically websites have used 'Identification' to authorize users. A user logs in and the relevant record is found in the database. RBAC has been widely deployed in Enterprise type settings or in 'tight' federations; where the IDPs and the RPs can collude to agree on Role names and Role interpretation. Claims Based authorization is the solution that is growing to address the needs of a distributed authorization framework or 'lose' federations. <br /><br />Roles are probably defined in the context of a 'vertical' (industry, community, academic practice, etc..). Claims are the raw data about the subject and 'tend to be' as objective as possible so that the consumer can apply its own policy.<br /><br />I personally believe that Claims Based is a powerful way forward and should be embraced, however, we also need to be realistic and pragmatic. In cases where there is a known tight relationship between the IDPs and the RPs mixing these 3 patterns together seems expedient. There is no point going to great lengths to build zero-knowledge identifiers if you KNOW that each relying party is going to then require an email address (unless you are also confident that the users have mechanisms to deliver and manage zero-knowledge email addresses).<br /><br />SO.... specifically.... <br /><br />* I think that the Library Community is homogeneous enough that we can define so mutually agreeable Roles, like the ones you suggested. <br /> ** Faculty (Academic libraries)<br /> ** Staff (all types of libraries)<br /> ** Student<br /> ** Adult<br /> ** Young Adult<br /> ** Juvenile<br /><br />* Where needed, service providers can establish mappings between PPIDs delivered by the infocards and internal IDs for Identification.<br /><br />* ILL and Electronic Resource Delivery (eBooks) will require Claims Based authorization to augment the Roles so that the systems know not just that the user is a patron, but that they should have access to 'this specific eBook' from 'this date to that date'. <br /><br />So the delivery mechanism that we are using, ws-* / Information Cards, IS a Claims Based framework, BUT, we are using the framework to deliver claims to enable all 3 authorization patterns.<br /><br />Do you agree?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-19355755463590927602009-01-20T13:56:00.000-08:002009-01-20T13:58:24.548-08:00The winner is:As you know, I have been trying to decide how I think we should model the ‘roles’ claims for the ICF’s pilot Library Card project (see my last post: The Claim Game). I have talked, emailed and blogged with a bunch of people who have opinions on the subject and have come to the following conclusions.<br /><br />Off the point for a moment: There seems to be some consensus that if the policy description and interpretation step that goes on between the relying party and the ‘selector’ was richer then we may have better options open to us. However, today the Information Card specification is what it is and I don’t recommend putting a hold on our project in the hope that it might change.<br /><br />The options that we have are either to have a single ‘roles’ claim that contains a list of the roles that the user has been granted, or, to have separate claims for each role. The separated claims could be on different cards but I see that option as being basically the same as option 2.<br /><br />Having thought about this a bunch I think that the better option is option 2, a separate claim for each role. This will force us to formalize and standardize the role names, which is not ideal, but, it provides the best privacy protection and ultimately the smoothest user experience. While the user experience may be a little more complicated on the face of it, I believe it is superior because it will be predictable. <br /><br />With this option the presence of the claim indicates the assignment of the role. The value of the claim is basically ignored, as it is in the selectors’ card selection process. If a resource indicates a specific role or set of roles that must be present to gain access; only cards capable of satisfying the policy will be presented as selectable cards. <br /><br />I look forward to hearing why I am wrong :-)=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-52455572714402329932009-01-06T12:13:00.000-08:002009-01-06T12:19:25.692-08:00The Claim GameI-Cards provide a mechanism to deliver claims to relying parties (RPs) . The first i-card claims that we all became familiar with were the ones built into the CardSpace v1 client. While one COULD build an RP that asked for claims that were not one of this standard set the chances of finding a user with a card that had any other claims was pretty slim.<br /><br />We are now entering the next stage of i-card evolution and adoption where we want to start to extend the list of claims. I am finding that the simple patterns established by the first claim set makes this issue seem more trivial than it is.<br /><br />The pattern that I personally, mistakenly, thought I was seeing in the WS-*, InfoCard, dance was:<br /><br />RP says to Card Selector: “I want a nickname claim”<br />Card Selector says to User: “Pick one of these cards that has a nickname claim”<br />User selects a card and the nickname claim from that card is sent to the RP.<br /><br />My misunderstanding was the assumption that the communication between the RP and the selector meant that I would only be able to select a card that would result in a successful transaction. Not only is this not true it is looking to me like I may get very little guidance from the selector as to which card I should select.<br /><br />In my nickname example above just having a nickname claim may not be enough to... for example... post a blog comment. The value of the claim may be null... The RP may tell me that someone with a different PPID has already used that nickname. And Nickname was an example that I picked as 'the most trivial self asserted claim'. When you get into claims of higher value this problem becomes more apparent. Try registering to leave a comment on Kims blog: All it requires is an email address claim BUT that email address is then validated via an email round trip (as it should be), my point being that the fact that the selector says a card can satisfy the policy of the site only gets me so far. <br /><br />SO... I foresee, or fear, this user experience:<br /><br /><ul><li>I navigate to a web site and see the i-card logo and click on it to 'login'.</li><li>The Card Selector pops up with... lets say... 5 cards highlighted.</li><li>I consider for a moment which one I want to send... and pick number 4.</li><li>The site then tells me that the VALUE in one of the fields is unacceptable (wrong issuer, non-unique, not a member of the formal options,etc..)</li><li>So... I try another of the cards that are highlighted and that one fails too.</li><li>So... I try another one... or did I try that one already?</li></ul><br />Not only is the experience nasty, I just submitted 4 sets of data to one RP in a VERY correlate-able way.<br /><br />So how do we avoid this pitfall?<br /><br />It is possible that all of this can be solved in the selector, maybe it already is and I don't know it, PLEASE let me know if it is! The in-selector solution would be that the RP can communicate more of its policy to the selector so that the selector can make smarter decisions based on claims values and claims metadata not just the presence or absence of a claim in the schema.<br /><br />Meanwhile... I have a problem... and I'm not sure what the solution is. Here's the problem:<br /><br />I want to issue a Library i-card. One of the logical claims that one makes about the holder of a library card is what roles they play at the library; note that I say roleS not role. It is very common for an individual to have multiple roles at the same Library; they may be staff and a part-time student, faculty and staff, faculty and alumnus, etc...<br /><br />So how do we model this in an i-card?<br /><br />There seem to be 2 solutions; have one claim that returns a multi-value response OR have a claim for each possible role.<br /><br />The first option; a single claim called 'library-roles':<br /><ul><li>In this case the RP always gets to know all of the roles of the current user even if all they needed to know is if they had a specific role.</li><li>I could have 4 cards highlighted in my selector but find that none of them deliver a claim that can actually satisfy the RP (after i have given them a LOT of information about myself). </li></ul>On the other hand:<br /><ul><li>In the vast majority of cases the user only has one library card and it will either work or won't work.</li><li>The RPs are likely to be libraries and therefore trustable anyway?</li></ul><br />In summary of option 1... can seriously compromise privacy, but that's OK.... if you don't care about privacy.<br /><br />Option 2 is have a claim for each role. With this option you can maintain privacy but at the cost of usability. As I navigate the RP site I will be repeatedly prompted for 'another' card (could be the same one) as I move to parts of the site that require different roles. In this case I progressively give up privacy, if I want to, in order to get access to functionality. This again assumes that the presence or absence of the claim is actually more important than the claim value, which in this case is always assumed to be 'true' in order for this scheme to make any sense.<br /><br />If you have managed to get to this point in this diatribe.... I would love to hear which option you think I should use... Or is there another option I haven't thought of?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com4tag:blogger.com,1999:blog-11741871.post-11731511170969489132008-10-16T06:52:00.000-07:002008-10-16T07:09:39.919-07:00Resolution RevolutionSo I learned a little this week about sockets and it has given me pause to think about the realities of 'success' in regards to MASSIVE the adoption of the protocols that I tend to talk about on this blog.<br /><br />They say a little knowledge is a dangerous this... well here I go... head first:<br /><br />DNS resolution has been under attack recently (last 6 month) from a <a href="http://lwn.net/Articles/289138/">new set of poisoning attacks</a>. One of the main reasons the attacks work is because DNS uses UDP and not of TCP. The basic fix that has been implemented is Source Port Randomization but even that has been brute force attacked.... so people speculate as to what else could be done. One idea was make every request twice and the answers MUST match (this is known as debouncing). Another option proposed is, just use TCP instead of UDP.<br /><br />So here's what I find interesting... The debounce option was rejected because it would double the amount of traffic on the DNS system; we would go from 2 packets on the wire to 4. It has been determined that the current DNS infrastructure is running at over 50% capacity so instantly doubling the load is simply not an option. SO... why not use TCP? Well, if you use TCP you have the 3 way handshake, then the query, then the response and then the fin and the fin ack.... 7 packets on the wire (and larger packets at that). So I find all of this fascinating in a purely academic way, this stuff is all new to me. (now I have a basis on which to go understand DNS Sec, that'll be next week's reading)<br /><br />Then I wander... is anyone doing the math? IF OpenID became ubiquitous, or InfoCards did, what would that look like at a packets on the wire level? Is there so much spare bandwidth and processing power now available that we don't have to worry about this?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-87213696007282318462008-10-15T09:23:00.000-07:002008-10-15T12:04:44.546-07:00Is this reputed to be a reputation?There's a great thread going on about reputation on one of the lists I read. I tried to respond to the thread, which is something I NEVER do, but apparently it has been too long since I was active so it wouldn't let me.... So I'm weighing in here for any one to check if they like.<br /><br />Another definition of reputation:<br /><br />Reputation is the result of running an evaluation algorithm over a set of input data. <br /><br />Some sample input data:<br /><br />a) Number of sale transactions and number of complaints<br />b) Number of IM connection requests and number of IM spam reports<br />c) Ebay reputation, Credit score and number of points on my drivers license.<br />d) How much 100 people, selected at random, like Diet Coke<br /><br />The evaluation algorithm can be very simple or very complex.... Ebay's is arguable very simple and Fair Issac's has a very complex algorithm.<br /><br />Arguably the reputation of a reputation could be measured based on the quality of its input data and the quality of the evaluation algorithm. <br /><br />Reputation system attacks tend to attack the data input stream, or depend on a delay between input and output. (I've written on this in the past.)<br /><br />As identity providers I think our first line of responsibility to reputation systems is the CONTROLED delivery of quality input data that is surrounded by enough metadata about collection/storage/retention and "whatever else" that anyone can run reputation evaluations against that data and reach meaningful conclusions. I can then feed that (anonymized?) data into the reputation service of my choice which will likely be dependent on the context of my current activity.<br /><br />If I want an agent at my smtp gateway to 'decide' if a piece of information should be delivered to my inbox I don't care what the sender says about themselves, I don't want to go query a bunch of reputation services to see if they know anything about this sender (which ones would I trust?). I want to have access to a set of data, signed by a reputable source, how long has the account existed, how many mail have been sent, how many complaints have there been, registration info(made available for bootstrapping) that I can put into my personalized reputation algorithm.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-1929367659214534442008-09-23T22:46:00.000-07:002008-09-24T05:58:37.034-07:00I did my best...Paul, sorry I can't help with the <a href="http://connectid.blogspot.com/2008/09/say-hi-to-dewey.html">fines</a> but I was very interested to see that you are checking out "that" kind of book ;-)=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-24984367947491476132008-09-22T20:03:00.000-07:002008-09-22T20:25:20.242-07:00The next stageWell now the rubber is going to meet the road....<br /><br />The people that I now call associates, and my boss, know a LOT more than I do about the management of massive repositories of distributed data. So now I get to test some of the ideas that I've talked about here over the years...<br /><br />I now work at <a href="http://www.oclc.org/us/en/default.htm">OCLC</a>, the Library People. My job is specifically working on Identity Management and Authentication. These things obviously only make sense in the context of controlling access to information resources.<br /><br />As I learn the differences between what I have guessed is important and what really is important for the OCLC use cases I'll let you know how good or bad my thinking of the last couple of years has been. <br /><br />I will still be engaged in the standards process and will bring the OCLC needs to the table as concrete examples of massive distributed identity use cases.... I think this is going to be fun!=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com3tag:blogger.com,1999:blog-11741871.post-5515526034716149222008-08-09T14:05:00.000-07:002008-08-09T14:20:52.268-07:00The times they are....If you are reading this you probably know me and my work.<br /><br />Together with my team of awesome co-workers we have tried to help move the art and science of distributed identity management and distributed data sharing forward. I think we have done some good work and would like to think that we have contributed positively to the general progress.<br /><br />Unfortunately, as many of you know, advancing technology doesn't actually pay the bills and we can't pay the bills any more :-(<br /><br />ooTao as we know is going to go away. I thought that we had a purchaser for the company but it looks like that is going to fall through. I am devastated to think that body of knowledge and the body of work that we have built up over the last 4 years is just going to evaporate but it looks like that might be what happens. The entire ooTao team is now out looking for employment, including me.<br /><br />I am still looking to see if anyone, with enough money to pay us, wants to try to keep the team together and keep the work going but I'm not feeling very hopeful.<br /><br />So if you want to employ one or more people passionate and knowledgeable about distributed identity and distributed data... just let me know... otherwise, I'm off on the next great adventure.<br /><br />I hope I'll end up in a position that I can continue to participate in the standards work. No matter what I will continue to post here periodically about what I'm doing that is in any way related.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com2tag:blogger.com,1999:blog-11741871.post-66156648452156847962008-05-30T09:36:00.000-07:002008-05-30T09:51:55.827-07:00A Wag for the TAGThe interference of the W3C in the XRI vote at OASIS is unprecedented and disturbing. The W3C has rebuffed all efforts by the XRI TC to engage in any form of dialog about the technical merits of XRI. Despite repeated attempts by the XRI community to show the use cases that XRI is solving the TAG make vague statements like 'you can do everything in URL'... This statement is clearly and patentley meaningless without specifics....<br /><br />It all well and good that SOME of the stuff that XRI does CAN be done in URI/URL but without specifying a STANDARD way of doing stuff the ability to do it is next to useless!!<br /><br />There are parts of XRI that you simply CAN NOT DO with URI.... Like resolve an abstract identifier (urn).<br /><br />There are hundreds of millions of users with services that use the xri specs (OpenID being the best known). The ONLY reason W3C cares about this is they think they CONTROL the internet and here is a spec that OBVIOUSLY solves wide reaching problems and it's not theirs.<br /><br />In my mind this is as subversive as the Net Neutrality issue... W3C is cynically trying to stifle innovation for pure 'not invented here' reasons. <br /><br />rant rave grr huff.... This pisses me off... PLEASE.... if you voted NO on the xri vote spend some time on the phone with me and talk with me about why you voted no and why I think you are wrong! Before undermining LOTS of hard work by LOTS of smart people at least understand the technology.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com2tag:blogger.com,1999:blog-11741871.post-86559240252692663972008-05-21T06:59:00.000-07:002008-05-21T07:28:58.251-07:00Let every eye negotiate for itself<a href="http://connectid.blogspot.com/2008/05/verified-by-ootao.html">Paul's response</a> to my latest post put me in mind of Claudio in Act 2 scene 1 of Much Ado About Nothing...<br /><br /><blockquote>Let every eye negotiate for itself<br />And trust no agent; for beauty is a witch<br />Against whose charms faith melteth in blood. </blockquote>Paul is correct that I must qualify my posts more carefully.<br /><br />There is as yet no agreement on all of the mechanisms of claim and assertion exchange. While the ability to differentiate a self asserted claim and an issuer asserted claim in a managed infoCard is useful in some cases it is not the ONLY answer to the problem. The fact that I have a widely deployed client provider that wants to consume claims in this way is a pure Business Detail that should not impact the purity of the technical discussion. <br /><br />As Paul points out a Better way to do this would be for us to deliver an 'Email' claim with enough metadata about how the claim was acquired and how it was or wasn't vetted that the RP could make its own decision as to the veracity of the claim. I probably should have implemented it this way even though the RP was asking for something else.<br /><br /><span style="font-style: italic;">Post Script</span><br /><br />That was meant to be wry bitting humor... not mean... does it sound too mean?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1tag:blogger.com,1999:blog-11741871.post-72711137112505621172008-05-20T12:40:00.000-07:002008-05-20T15:54:04.715-07:00The Claim GameooTao's Managed InfoCards now include a verified email claim and verified i-name claim.<br /><br />If you want to consume these claims you will need to ask for:<br /><blockquote><span style="font-size:85%;">http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/emailaddress<br />http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/iname</span></blockquote>I have blogged previously about how you might <a href="http://xditao.blogspot.com/2007/06/validating-i-name-claims.html">validate an iname claim</a><br /><br />We are publishing our own 'white list' of claims providers that we consider 'trustworthy' in order to 'trust' the verified email claim. More on that soon.<br /><br />If you want to start consuming our verified claims at your RP just let us know and we can do some testing together.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-34876256078516596232008-05-17T07:54:00.000-07:002008-05-17T08:29:56.704-07:00Did Info Card help?I like InfoCards... I like the idea that I will not have to remember the usernames and passwords. I am confident the MS will work out how to solve the 'portability issue'... BUT.... I just went through InfoCard hell!! I'm still shaking as the adrenaline that built up is trying to drain from my body... this can't be good for me. Let me tell you what happened.<br /><br />After a long week at IIW and Data Sharing Summit and OpenSocial Spec meeting, I am finally checking in on the blogosphere at 5:30 am on Saturday morning and I see this really cool thread on <a href="http://www.identityblog.com/?p=986">Kim's blog</a>. It's all about the qualities of Distributed Data Management that I have been talking about for years, but, it's Kim and <a href="http://www.vquill.com/">Dave</a> and <a href="http://blogs.oracle.com/clayton/newsItems/viewFullItem$32">Clayton Donley</a>, who is the Senior Director of Development for Oracle Identity Management.... I get so excited, I have to add a comment and tell them about ooTao's work in the space (although Kim is meant to know :-) ).<br /><br />And that's when the problems started...<br /><br />I can use digitalMe on my mac to log into our RPs and even to <a href="http://self-issued.info/">Mike's blog</a>, but it will not work on Kims blog. I spent a while restarting things; browsers, selectors, OSs, this is just habit as a long-time Windows user, nothing helped.<br /><br />So I upgraded and downgraded the versions of DigitalMe and tried to log in to no availe. For any who care the error I get is: 'unknown option privfile... blah blah'.<br /><br />Then I remembered, my old XP PC that is now the kids, should still have InfoCard selector installed so I put aside my mac and power up the old PC. First attempt to login at Kims blog tells me that 'InfoCard isn't installed' which seems strange, since I remember installing it. So I poke around and find that I DO have it installed but I don't have any cards defined... I add a card... I return to Kims blog... I click and YES, the selector invokes and I can see the card and I select it... and I am asked if I want to be redirected to an error page... which isn't exactly what I want but, what the hell, I've come this far.<br /><br />The error page informs me that the temporal offset of the requesting token is larger than the requisit 300S. Those aren't the exact words but believe me the error message did not say... 'The Client and Server Clocks don't match'... So I unpacked the message and realized that I needed to change the time on the PC so that it matched Kims server within 5 minutes.. I just had to hope that Kims clock was close to right. So I changed the time a few times and yes.... finally... I logged into Kims blog and left a comment.<br /><br />Unfortunately by the time I got there, my enthusiasm and excitement for the topic had been morphed in to frustrated anxiety so my comment is no-where near the 'tone' I originally intended. There should probably be some joke I can make here about 'Claims Transformations' as this STS certainly transformed my claims... BUT... I have now been trying to write, writing, writing about this damn post for 3 hours...<br /><br />I think it was worth it though if I can finally get these guys to understand what it is we have built.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com4tag:blogger.com,1999:blog-11741871.post-11025397896852669702008-05-06T07:47:00.000-07:002008-05-06T08:21:35.662-07:00iPages a go-goI was reading <a href="http://epeus.blogspot.com/2008/05/portable-apps-not-data.html">Kevin Marks post</a> that looks at <a href="http://ideas.4brad.com/data-hosting-instead-data-portability">Brad Templeton's post</a> about the interplay between data portability and behavior portability. As I commented on Kevin's blog I agree with them 80% but think that Brad's proposal has one flaw.<br /><br />I disagree that it is practical or desirable to create a centralized data store. I think there are a couple of issues with that model. The first is the security implications of having everything in one place... that scares me. The second issue is, I think key, to the success of this model...<br /><br />The 'place that I have access to all my data and can therefore run my OpenSocial apps', lets for the sake of ease call it my 'iPage' can and should provide me all of the user interactions I need to manage my virtually aggregated data. Specialized 'Widget Providers' should give me widgets that give me data domain specific user interactions through which I can specify my favorite music, food likes and dislikes, rental car preferences, etc... BUT there is a world of data that is collected about me, and should be FOR me, buy people and systems that are much better qualified to know and assert those things than I am... Like medical information, qualifications, financial instruments, transactional histories of all kinds, what was done to my car at its last service, etc...<br /><br />This is why we have BUILT a system that has a data abstraction (xdi/higgins) behind the OpenSocial container rather than a database. The abstraction can provide (bi-directional data access) data to widgets that is stored locally or data that is stored remotely (or a mix of both), the widget neither knows nor cares. <br /><br />Using OPEN distributed identity standards (OpenID, oAuth, ID-WSF, InfoCards, FOAF, XFN) and OPEN data abstraction standards (XDI, Higgins,XML,RDF)... This can be done today... we've done it... This truly enables VRM in a broad and flexible way.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-42962186662371002472008-04-21T08:31:00.000-07:002008-04-21T09:44:19.793-07:00Steve does it again...If you read this blog you get to watch me struggle to articulate some of the important subtleties of working with XRI, XRDS and XDI. Check out this <a href="ftp://sandbox.myxdi.net/papers/context-sensitive-identifier-mappings.pdf">article</a> written by ooTao CTO Steven.Churchill which show very clearly who the real brains of this operation is.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-80958309587746268382008-04-16T18:49:00.000-07:002008-04-16T19:00:58.817-07:00More on Claims and XRDSI was recently contacted by Bob Wyman in regard to an earlier post of mine... the first question was:<br /><blockquote>Some time ago, you wrote:<br /><blockquote><br />SEPs in XRDS must be considered self asserted<br />claims and as such should not be trusted on their<br />face. Service Providers should publish the<br />mechanisms by which SEP claims should be validated<br />to be about a specific subject (authenticated<br />identifier). (ooo… I feel another spec coming).<br /></blockquote><br /><br />Did that spec ever get written?<br /></blockquote>I had to respond that I never did write that spec but offered to consider his use-cases if Bob thought it would be useful. He sent me these use cases:<br /><br /><blockquote>Well, there are two kinds of things that I would like to be able to validate. The generic issue here is one of XRDS spam...<br />1. If I'm hosting a blog for someone and there is an XRDS file with a SEP that forwards to that blog, how do I assure a third party that the XRDS file belongs to the person for whom I am providing blog hosting?<br />2. If an XRDS file contains a link to some descriptive service (perhaps an XML file that describes the business and claims that the subject is a "Pizza Parlor"), how do I make the assertion that I know the subject to be, in fact, a Pizza Parlor?</blockquote>And I responded like this.... NOTE: if you manage to read the whole thing AND find the intentional mistake... you win a prize (at least you may be entered into a random drawing and have your name honorably mentioned by me to my family over diner one night).<br /><br />I SAID: -<br /><br />First I have to give the disclaimer.... these ideas are just our thinking on the subject, we do not represent the XRI TC or any other body, blah, blah, you get the idea...<br /><br /><a href="http://thread-safe.livejournal.com/">John Bradley</a> and I spent a good couple of hours talking this through and have come up with 2 answers for you... One is the practical, how you should probably do it today kind of answer and the other is the 'doing it right' answer, which would mean taking on a lot more of our abstract thinking and an XDI server. The 'simple' answer still has problems that I will highlight...<br /><br />Use Case 1) How to assert at an arbitrary http endpoint (web page, blog) a relationship with a specific XRDS.<br /><br />The 'simple' solution is that the http endpoint support YADIS discovery to 'get' the desired XRDS. The claim in this case would be validated by reseprocity. The XRDS returned by YADIS discovery MUST have EITHER an 'EquivID' or a 'CanonicalEquivID' that is the URI of the original endpoint.<br /><br />The one problem with this 'simple' approach is if you as the service provider or the end user actually have the ability to put the EquivID element into the users' XRDS. If, for example, this was Blogger blogs and Blogger OpenID 2.0 XRDSs then you would have the ability to edit the XRDS and the blog to create the reciprocal relationship. If the use case is broader than that you need to fall back on other mechanisms for the 'other end' of the relationship to be established. The options there would be:<br /><br />a) tell the user to 'go edit their XRDS' - and wish them luck :-)<br /><br />b) Use XRDSPP (XRDS Provisioning Protocol) - which is partially specified here: http://dev.inames.net/wiki/XRDSP_Spec and partially specified here: http://xpp.seedwiki.com/wiki/xpp/specs and not yet implemented or deployed anywhere that I know of. (although it is the 'next thing on our list' as MANY use cases depend on its existence)<br /><br />Use Case 2) How to assert a third party claim in an XRDS.<br />I'm not SURE that I have understood your use case 100% so I will be verbose about the problem that I am solving in case it isn't the question you asked...<br /><br />What is not clear to me from your question is what an RP would be looking for in the XRDS .... Would they be looking for "what does Service XYZ know about this entity" OR would they be looking for "what claims are available about this entity" OR would they be looking for "Is the entity represented by this XRDS a Pizza Parlor?"<br /><br /><br />If the question is: What does 'this service that I trust' know about the entity represented by this XRDS then the flow would be:<br /><br />1) RP looks for the CanonicalID associated with the Authentication Service SEP that they use to authenticate this entity (if they interact with the entity using OpenID then they need the CID of the XRD that contains the OpenID SEP, if they have a 'signed document' from the entity they would use the CID of the XRD that contains 'KeyService' SEP (the place you get the public key)) .<br /><br />2) The RP presumably knows the URI of 'this service that I trust' so they simply parse the CID, AND THE SERVICE TYPE, to the 'trusted service' and the trusted service returns 'claims' about the specified entity. SAML would be an obvious choice for expressing the claims but one could use any format one chooses.<br /><br />If the question is: What claims are available about the entity represented by this XRDS then flow flow would be:<br /><br />1) Perform Service Discovery for a 'Claims' service (not yet formalized but we could make one up on the fly if we needed to).<br /><br />2) Perform Service Discovery for the AuthN service (like above) to get a 'Key' CanonicalID.<br /><br />3) Ask the claims service (assuming that the claims service has a well known API) about the entity by passing in the CID and the AuthN Service Type.<br /><br />4) Get back a list of claims... The claims should always be verbose and specific... not: 'this guy is over 18' .... but "Claim service A says - the guy who on this date and time had the credentials for the OpenID Service for CID =!abcabc is over 18". As per my blog post yesterday about "XRDS Caching" this claim could be cached in the SEP to optimize this interaction. Depending on how the claim is retrieved, from cache or from the service itself will dictate the level of crypto verification you might want to apply to the claim.<br /><br />If the question is: Are you a Pizza Parlor then the flow would be...<br /><br />1) Get the XRDS for the CID (no service selection) and iterate over the XRD level Type elements to see if anyone has claimed that this is a Pizza Parlor. The Type element of the XRD is an XRI that might me in the 'self issued' form.... "xri://+pizza.parlor" or it may be in the 'asserted' form... xri://@google*(+pizza.parlor). In the assert form, if you decide to trust the asserter, you can validate the claim by the same means as answering the first question in this use-case where google just became your 'trusted service'.<br /><br />AND THAT"S THE END OF THE SIMPLE ANSWER :-)<br /><br />So in fact the 'how it SHOULD be done' (according to Andy Dale) answer is a lot simpler if you can overcome one pre-requisite..... First install your XDI server... the rest is easy, really... if you want to know I'll write up how that would work.<br /><br />Did you spot the mistake?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com6tag:blogger.com,1999:blog-11741871.post-11845743502166159052008-04-15T07:37:00.000-07:002008-04-15T08:31:49.385-07:00XRDS patternsTalking with <a href="http://thread-safe.livejournal.com/">John Bradley</a> yesterday we got into some best practice ideas for XRDS usage. These probably need to me formalized somewhere other than my blog as I think they are important, but here's a first brain dump for you...<br /><br />1) More abstraction in our Service End Points (SEPs) - Right now we have a tendency to put a uri in the uri element of the SEP. The problem with this is that if the service provider changes their coordinates (or any other detail about their service) they have to change all of their customers SEPs. What we probably want to do is in any given individual's XRDS is provide a pointer to the Service Provider.... Jane uses @xyz for this service.... @xyz is then dereferenced for the access details. If @xyz makes any changes to their service they only have to change the SEP at the @xyz XRDS.<br /><br />In MOST cases this can be achieved by using an Service Level Ref. In MOST cases the Canonical ID of the XRD that contains the final SEP is actually irrelevant so having many SEPs Ref to the providers' SEP works fine. In cases where the CID does matter (like in an AuthN service) we have to do something else.. An XRI in the URI element would do the trick but that is going to have to be handled by the application as the resolution client will not ''automatically" dereference the xri. However, all the app will have to do is make another call to the resolver while remembering the CID from the first resolution call.<br /><br />2) XRDS Level Chaching - There are several SEPs that we are defining that, in their simplest uses, only expose a single piece of information. Examples of these are the 'Key Service' where in most cases you simply want the current public key associated with the identifier, or the STS service, where you are simply looking for an assertion of who is the issuer of mCards for this xri. In these cases it is burdensome, especially if we add the abstraction I proposed above, to have to resolve the SEP and then invoke another service to get a single piece of information. We have found that it is convenient in these cases to cache the pertinent piece of information directly in the XRDS. This way you can optimize most discovery and validation interactions. If you find that the cached value is "not what you would expect" (does not provide a public key that matches the signature provided) you can then invoke the described service to find out if the signature used an older, revoked, compromised key.<br /><br />What do you think?=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com0tag:blogger.com,1999:blog-11741871.post-60037033080313339272008-04-10T22:03:00.000-07:002008-04-10T22:10:44.451-07:00wow...what a weekWell, RSA is over and we finally get to slow down again.... The last few weeks have been crazed finishing everything that we wanted to get finished to show at RSA. It is VERY cool... the iPage framework is an embodiment and implementation of a lot of the ideas I have been sharing here for the last 3 years. It is real user centric information management. It allows anyone to create a collection of claims from various places and then project them back out into the world progressively and securely. Over the next couple of weeks I will publish more information about iPages and how they work and instructions how to get one of your own. <br /><br />Watch this space.=andy.dalehttp://www.blogger.com/profile/15224884476207310779noreply@blogger.com1