Wondering about Portable Contacts import from Plaxo for chi.mp
Avatar

George Fletcher

Vcard Download vCard   what is this?
Rss_icon

Recent Activity

Filter by:
All
  • Identity as an Attribute
    A while back I posted a couple of entries on the concept of an identity token. The idea being that a client/requester/relying party could request an identity token from the Identity Provider (IdP) when authenticating the user and then use it when accessing protected resources to represent who is making the request. This becomes very important in person-to-person sharing use cases.

    One such use case that recently appeared on the OpenID specs listserv is the need to access protected <Link> elements in a user's XRD/JRD. For example, I want to allow family members to be able to discover my family photo albums but keep those links restricted from public access. The basic need is that the requesting client/service needs to "prove" to my XRD provider that they are a "family member". A very easy way to do this is for the requesting client/service to obtain an "identity claim" from the family member's identity provider and pass that along to the XRD provider. This of course would most like be in the form of some structured OAuth token.

    Thinking about it this way, the user's identity is really just a 3rd party asserted attribute. 3rd party because the client is the 1st party in this scenario and will be the entity presenting the attribute to other services.

    This concept of 3rd party asserted attributes is not new. There have been many discussions and posts about how to obtain an "over 18" attribute from the DMV and store it in the IdP. What makes representing the user's identity different in this case is that often, the user's identity is the key that gets them access to their resources. Thus, this identity attribute has to be recognized as just a verified identifier (i.e. like relying parties want a verified email address) and not some sort of authorization token.

    My one concern has to do with whether 3rd party asserted attributes should just be bearer tokens? or whether they need some holder-of-key mechanism to ensure that only the client that is issued the 3rd party asserted attribute can present it in future requests.

    Previous posts:
    Protecting "discovery" information?
    Open Identity Token
    Open Identity Token and Personal Discovery Service (Praveen Alavilli)
    Continuing the discussion...




    Identity, Token, Sharing, Attribute, OAuth, XRD
    3 months on
    Identity in Practice
  • OpenID Summit Day 2
    Day 2 of the OpenID Summit was an eclectic mix of updates on current efforts, new proposals, and Issues. The day's agenda and related presentations can be found on the OpenID Wiki.

    I found the Browser-Assisted Login presentation by Dan Mills (Mozilla Foundation) especially interesting. I believe that some level of identity agent (whether that be the browser or some other process running on the user's device) to be the best way to solve the current usability problems that users face. Their current approach leverages host-meta which defines a link to a JSON based site meta-data document (JSON instead of XML just because that's much easier for the browser to parse). Currently they don't support unsolicited assertions in their OpenID implementation. This is great work, and I believe that with a mechanism to sign the site specific meta-data document and the ability to support unsolicited assertions (protects against phising), this will be a great solution for users.

    Mike Jones (Microsoft) also presented on identity agents and Microsoft's work in integrating OpenID and Cardspace. Mike outlined 3 key requirements for allowing identity agents to integrate well with web sites.
    1. Web sites need to be able to publish it's requirements to the identity agent
    2. Web sites need to be able to detect the presence of the identity agent
    3. Web sites need to be able to invoke the identity agent
    Initially I didn't think that requirements 2 and 3 were necessary but I can see some use cases where this might be required. I believe the preferred design should be totally passive markup by the web site with the identity agent invoking the user's desired/expected behaviors.

    Brian Ellen (JanRain) [Challenges faced with RPX], Allen Tom (Yahoo!) [What an RP wants from an OP], and Chuck Mortimore (Salesforce) [Multi-tenancy at Salesforce.com] all talked about issues relating to being a web site that accepts OpenIDs. These talks expounded on the issues list from Day 1 and provided additional clarification.

    John Panzer (Google) [Webfinger], Breno de Medeiros (Google) [Artifact binding], and Nat S (NRI) [Contract Exchange] gave explanation and status of their current work in these areas. Key take aways for me were ....
    • Webfinger can be used for generic discovery of any identifier
    • Artifact binding will allow OpenID to support any token type not just the current OpenID assertions. Artifact binding is also key for OpenID to support LoA2 based web sites.
    • Contract Exchange provides mechanism to get contracts digitally signed by both parties.
    Pamela Dingle (Ping Identity) spoke on the economic deployment of OpenID in the enterprise and it's associated services. In these environments its critical to be able to mix protocols and from a user's perspective seamlessly navigate between OpenID and SAML (for example).

    Mary Rundle (Microsoft) spoke on the necessity of OpenID to engage the public policy makers because public policy can have a significant effect on technology. She encouraged the OpenID Foundation to establish a process for engaging in the public policy discussion.

    Joseph Smarr (Google) gave an interesting proposal for how to make OpenID and OAuth easier for developers. This sparked great discussion and debate including ad hoc sessions. The goal of this proposal is to make it as easy as possible for developers to integrate OpenID/OAuth into their web sites.

    Sarah Faulkner (Microsoft) lead a discussion on whether email address should be used as an identifier for the user. One clarification from the discussion is that email addresses are good identifiers for what the user knows (i.e. what the user can type into a web site). However, they are bad database identifiers. So OpenID should support using an email address as a way to bootstrap into a more permanent/consistent identifier for the user (this is pretty much what webfinger provides).

    I also lead a quick discussion around the issues with OpenID and user logout. We didn't reach any conclusions. I see three possible "solutions" to this issue, listed in my order of preference:)
    1. Train the user to log out of their OS session. If the user has checked the "Remember me" or "Keep me signed in" option then logout is useless anyway.
    2. Instrument the browser to keep track of where the user goes and the browser can log the user out (either by clearing cookies or calling an API at the web site). This makes it easy for the user to choose when they want to just log out of a site (click the web site's logout link) vs log out of all sites (click a button on the browser).
    3. Enhance the OpenID protocol to support a logout mechanism with the option for the user to either just log out of a single site or log out of all web sites.
    The result of all the presentations and discussion is the formation of 5 new OpenID Foundation working groups. The following is taken directly from the OpenID Wiki page.
    •  Discovery
      • Chair: Allen Tom / Mike Jones
      • Scope: URL, acct:, active client (discovery about OP and RP)
    •  Attribute Schema
      • Chair: Joseph Smarr
      • Scope: How to ask for and get rich, consistent common extensible data attributes (attribute discovery)
    •  UX Guidelines
      • Chair: Chris Messina
      • Scope: Guidelines for how OPs and RPs provide a consistent user experience
    •  Policy & Certification
      • Chair: Eric Sachs
      • Scope: Define scope
    •  Core Protocol
      • Chair: Dick Hardt
      • Scope: active client, message verification, AX/CX, OAuth, non-browser

    Most of the presentations from the OpenID Summit can be found here.
    4 months on
    Identity in Practice
  • OpenID Issues List
    Yesterday at the OpenID Summit a number of companies presented on the issues they have experienced with evaluating and/or deploying OpenID. Here is my summarized list in no particular order.
    • Value Proposition is not always clear
      • Authentication isn't enough, need identity attributes (AuthN + AuthZ)
      • The more marketable attributes the better
      • Need a standard "profile" object with "trusted/verified" attributes
      • Data sharing when the user is not present
      • No clear way to push back activity into the user's activity stream
    • Usability
      • User's don't know their OpenID, use email addresses instead
      • Depending on the site requirements, the user may still have a registration to go through (e.g. site must collect age/gender/zip)
      • First time experience is different at each site
      • Customer care is difficult because the user likely doesn't know their OpenID (OpenID 2.0 IDs are often machine generated)
      • User confusion over the logout experience
        • Local logout just from the site
        • Global logout from all sites
      • User confusion over the login experience
        • Every pop-up UI is different
        • Should the user "link" their OpenID to their existing account at the RP?
        • Should the user create a new account at the RP based on their OpenID?
      • OpenID and OAuth both have "login events" but they mean different things
    • Better non-browser support
      • Devices (e.g. netflix, xbox, zune, etc)
      • Mobile devices (lose 70% of population in Japan if OpenID doesn't support mobile)
      • Rich client applications
    • Trust / Certification
      • How does the RP know it can trust the OP to security authenticate the user?
      • How does the OP know it can trust the RP with the identity attributes shared?
    • Security and Levels of Assurance
      • Need an independent security review by an expert
      • Cannot meet higher levels of assurance than LoA1 without protocol changes
      • Need an attribute profile to meet LoA2 requirements
    • E-Commerce
      • Who is liable/responsible if the user can't log in to their paid service because their OP is down?
      • How does OpenID make the check-out process better? more streamlined?
      • More e-commerce related attributes (e.g. billing/shipping address)
      • Portable reputation
      • User's want privacy to control what attributes/info is shared with the merchants
    • Interoperability
      • Need better / automated testing tools for core libraries and services
      • OPs have to tweak their implementation for specific RPs
      • RPs have to tweak their implementation for specific OPs
      • URL length can cause problems for some implementations
      • No way to move a 1.1 HTTP OpenID to a secure HTTPS one
      • Inconsistent implementations of Attribute Exchange
    • Ease of Adoption
      • Not easy to set up based on existing libraries
      • No simple JS library that enables OpenID without server development
      • OpenID + OAuth hybrid has too many secrets
    • Privacy
      • Must protect the user's rights
      • Needs to be under the user's control
      • Activities need to be un-correlatable (if that's what the user wishes)
      • Can't share email if maintaining the no correlation privacy constraint (Contact service?)
      • User must have access to their settings and activities at each site

    I'm sure I've missed some so please feel free to add to the list.
    5 months on
    Identity in Practice
  • Email Verification and Identity Federation
    Most sites today, when registering a new user, invoke some form of email verification. They ask the user for their email address, send the user an email, and ask the user to click a link in the received email. This ensures the web site has a "valid" email address for the user.  While not ideal, this works today as the user is "registering" directly with the web site.

    Now enter identity federation and the situation changes. If I can log into the web site using an identity I already have, what does this mean for the email verification process? Does the web site need to still send me through that out-of-band email verification process? Or can something better be done to improve the user experience?

    The answer to that question is yes, but it takes the web site changing their perspective on email verification. Instead of verifying the email address, the web site needs to verify the user (via identity federation) and use the identity protocol's attribute mechanisms to retrieve a verified email address. The difference is subtle but important.

    Let use the following scenario as an example. Using webfinger as a way to bootstrap from an email address to an identity provider...
    1. Alice goes to a new web site (http://relyingparty.example.com)
    2. Alice enters her email address (alice@example.net)
    3. The web site (relyingparty.example.com) uses webfinger to discover Alice's OpenID Provider
    4. The web site starts the OpenID authentication flow with Alice's OpenID Provider requesting an email address as a required element via Attribute Exchange (AX)
    5. Alice authenticates to her OpenID Provider and consents to sending her email address (alice.smith@example.com) to the web site. Note that Alice's OpenID Provider always returns a verified email address via AX.
    6. The web site receives the successful authentication response and retrieves Alice's email address
    Note that the verified email address returned from the identity provider is different from the one Alice entered at the site. This is the subtle difference that web sites need to consider. It doesn't matter which email address the user uses when interacting with the web site. What matters is that the web site has a mechanism to associate a verified email address with authenticated users.

    As identity federation grows, and web sites adopt this approach, the user experience will improve as there will be no out-of-band messaging required to start engaging with a web site.
    5 months on
    Identity in Practice
  • OpenID 2.0 Provider support live @ AOL I'm excited to announce that the AOL Identity Services team has fully deployed OpenID 2.0 Provider support. Directed identity flows are now enabled so just entering 'aol.com' into an OpenID field will start the authentication flow. In addition to directed identity, this release also supports "check immediate" flows, SREG, AX, UI (popup browser), PAPE (as required by the ICAM OpenID 2.0 Profile) and of course the ICAM OpenID 2.0 Profile itself.

    We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.

    In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.

    http://axschema.org/namePerson/friendly
    http://axschema.org/contact/email
    http://axschema.org/birthDate
    http://axschema.org/person/gender
    http://axschema.org/contact/postalCode/home
    http://axschema.org/contact/country/home
    http://axschema.org/pref/language
    http://axschema.org/pref/timezone

    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country


    Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.

    While there is still a lot to do, it feels really good to finally reach this milestone.
    5 months on
    Identity in Practice
  • IIW #9 : Making it all work If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.

    Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.

    I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.

    I'm expecting discussions like this to be a key part of IIW #9.

    Internet Identity Workshop
    Registration
    ~1 year on
    Identity in Practice
  • IIW #9 : Making it all work If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.

    Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.

    I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.

    I'm expecting discussions like this to be a key part of IIW #9.

    Internet Identity Workshop
    Registration
    ~1 year on
    Identity in Practice
  • User experience and Levels of Assurance The US government recently (Aug. 10th) held an Open Government Identity Management Solutions Privacy Workshop to discuss Trust Frameworks, Levels of Assurance and Privacy. At this workshop the government introduced a process for the adoption of any identity technology and a process for the adoption of any Trust Framework as managed by a provider (e.g. a Trust Framework Provider [TFP]). Both documents can be downloaded from the above link.

    One of the key points brought out at the meeting is that user experience (UX) is critical as users navigate government web sites that potentially require different levels of assurance (LOA) (see OMB M04-04). While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over. I believe UX and transitioning between levels of assurance is one of the critical issues to solve.

    While specific technologies may be restricted to certain levels of assurance, the user experience should be agnostic to the technology required to implement any specific use case. In this context I'd like to propose the following multi-LOA use case as one possible way to provide a good user experience.

    1. User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
    2. The user is redirected to their consumer LOA1 credential provider and logs in
    3. The user is redirected back to the govt web site with an LOA1 credential
    4. The user interacts with the web site
    5. The user clicks on an option on the web site that directs them to a new site (or a service within the existing site) that requires a LOA2 credential
    6. The user arrives at the new site and does not have a LOA2 credential
    7. The site informs the user that they need a more secure credential and that they can get one from the following locations
    8. The user selects one of the providers and is redirected to that site
    9. The LOA2 provider asks the user if they want to use existing LOA1 providers as a factor in the LOA2 credential
      • here I'm thinking that an LOA1 credential could be used in bootstrapping to the LOA2 credential)
    10. The user selects their current LOA1 provider (the one they used when logging into the govt site)
    11. The user goes through some identity proofing process (note that this could happen off line if necessary).
      • The point is that the user ties their LOA1 identity to the LOA2 provider. This helps with seamless transition between levels
    12. The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
    13. The user enters the one-time-pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting web site


    I'm sure I've left out some critical steps or places where the above does not comply with assurance framework requirements. I would appreciate feedback as to whether the general idea is viable. I would hope that one goal of this effort would be to protect the user (as much as possible) from having to increase the number of identities they manage.
    ~1 year on
    Identity in Practice
  • User experience and Levels of Assurance The US government recently (Aug. 10th) held an Open Government Identity Management Solutions Privacy Workshop to discuss Trust Frameworks, Levels of Assurance and Privacy. At this workshop the government introduced a process for the adoption of any identity technology and a process for the adoption of any Trust Framework as managed by a provider (e.g. a Trust Framework Provider [TFP]). Both documents can be downloaded from the above link.

    One of the key points brought out at the meeting is that user experience (UX) is critical as users navigate government web sites that potentially require different levels of assurance (LOA) (see OMB M04-04). While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over. I believe UX and transitioning between levels of assurance is one of the critical issues to solve.

    While specific technologies may be restricted to certain levels of assurance, the user experience should be agnostic to the technology required to implement any specific use case. In this context I'd like to propose the following multi-LOA use case as one possible way to provide a good user experience.

    1. User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
    2. The user is redirected to their consumer LOA1 credential provider and logs in
    3. The user is redirected back to the govt web site with an LOA1 credential
    4. The user interacts with the web site
    5. The user clicks on an option on the web site that directs them to a new site (or a service within the existing site) that requires a LOA2 credential
    6. The user arrives at the new site and does not have a LOA2 credential
    7. The site informs the user that they need a more secure credential and that they can get one from the following locations
    8. The user selects one of the providers and is redirected to that site
    9. The LOA2 provider asks the user if they want to use existing LOA1 providers as a factor in the LOA2 credential
      • here I'm thinking that an LOA1 credential could be used in bootstrapping to the LOA2 credential)
    10. The user selects their current LOA1 provider (the one they used when logging into the govt site)
    11. The user goes through some identity proofing process (note that this could happen off line if necessary).
      • The point is that the user ties their LOA1 identity to the LOA2 provider. This helps with seamless transition between levels
    12. The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
    13. The user enters the one-time-pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting web site


    I'm sure I've left out some critical steps or places where the above does not comply with assurance framework requirements. I would appreciate feedback as to whether the general idea is viable. I would hope that one goal of this effort would be to protect the user (as much as possible) from having to increase the number of identities they manage.
    ~1 year on
    Identity in Practice
  • ProtectServe and "Social relationship" authorization In a post today, Paul highlights a form of authorization that is not yet fully fleshed out in the ProtectServe architecture...
    Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both

    1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
    2) an individual with some defined social relationship to themselves

    ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.

    Of course the mention of ProtectServe is referencing the recent work of Eve Maler and team regarding a proposal to help simplify authorization management for users in the "distributed web".

    I believe that it should be possible to extend the Authorization Manager (AM) to leverage social relationships as a mechanism for the user to control access to protected resources. One of the use cases Eve mentions in this post is ...
    Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group

    Paul correctly points out that the Liberty Alliance People Service is built for just such a task. As it turns out Portable Contacts provides very similar functionality and is based on OAuth (the same base as ProtectServe). The Portable Contacts (PoCo) specification allows for grouping of contacts in an arbitrary manner using tags so the examples Paul gives are easily mapped. One missing feature of the current PoCo spec is that it doesn't support "membership queries" which means that more information is leaked to the Service Provider than necessary.

    Let's look at this use case in more detail. Assuming that Alice has created a resource at her photo service for the vacation photos, and also assuming that Alice has identified the desired set of individuals in her PoCo service with a tag of 'VacationPhotos', all Alice needs to do is associate this tag with the desired resource. So let's assume this is possible within the AM. Finally, let's assume that Bob is one of the individuals with a 'VacationPhotos' tag in Alice's PoCo service.

    The basic flow is that Alice sends Bob the link for the protected vacation photos. Bob clicks on the link and is taken to the photo service via his browser. The photo service check with the AM to determine whether the resource is protected or not. Since the resource is protected, the photo service asks Bob to authenticate. Based on Bob's authentication, and his membership in Alice's 'VacationPhotos' group, Bob is given access to the photos.

    The interesting twist with this particular use case is that the "Consumer" is really a user (i.e. Bob) who wants to view Alice's vacation photos. So when Bob tries to access the vacation photos resource that Alice shared with him, he accesses the service provider directly. At this point the SP checks with the AM regarding the authorization rules for the resource. However, Bob doesn't have a Consumer "token and secret" with which to sign his request to the SP. Instead he is accessing the SP directly via his user-agent. What Bob can do is authenticate himself to the SP using some authentication means. This is necessary as an identifier is required to determine membership in Alice's 'VacationPhotos' group.

    This leads to the question of who should manage the relationship with Alice's PoCo service to do the "membership" check? I can see two options...

    1. The AM maintains the authorization requirement (e.g. consumer must be member of Alice's VacationPhotos group) but the SP does the actual membership check. In this model the SP needs to set up a ProtectServe based relationship with Alice's PoCo service. Then when the SP authenticates Bob and has an identifier for him, it can check directly with the PoCo service determining membership based on the "contract" received from AM. This means that the SP must be able to interpret and process the "contract" on behalf of AM.

    2. The AM maintains the authorization requirement and also does the membership check with the PoCo service. In this model, the SP will need to forward Bob's identifier to the AM in order for the AM to perform the "membership" check and determine the state of the authorization. Or the SP could redirect Bob to the AM but I would that such a UX would most likely confuse the user. I do think there is a interesting privacy question on whether the SP should be allowed to forward Bob's identifier to the AM without Bob's consent.


    I'm not sure which method I like better. Maybe others have better solutions. Thoughts?

    Update: Corrected my ProtectServe typos:)
    ~1 year on
    Identity in Practice
  • ProtectServ and "Social relationship" authorization In a post today, Paul highlights a form of authorization that is not yet fully fleshed out in the ProtectServ architecture...
    Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both

    1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
    2) an individual with some defined social relationship to themselves

    ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.

    Of course the mention of ProtectServ is referencing the recent work of Eve Maler and team regarding a proposal to help simplify authorization management for users in the "distributed web".

    I believe that it should be possible to extend the Authorization Manager (AM) to leverage social relationships as a mechanism for the user to control access to protected resources. One of the use cases Eve mentions in this post is ...
    Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group

    Paul correctly points out that the Liberty Alliance People Service is built for just such a task. As it turns out Portable Contacts provides very similar functionality and is based on OAuth (the same base as ProtectServ). The Portable Contacts (PoCo) specification allows for grouping of contacts in an arbitrary manner using tags so the examples Paul gives are easily mapped. One missing feature of the current PoCo spec is that it doesn't support "membership queries" which means that more information is leaked to the Service Provider than necessary.

    Let's look at this use case in more detail. Assuming that Alice has created a resource at her photo service for the vacation photos, and also assuming that Alice has identified the desired set of individuals in her PoCo service with a tag of 'VacationPhotos', all Alice needs to do is associate this tag with the desired resource. So let's assume this is possible within the AM. Finally, let's assume that Bob is one of the individuals with a 'VacationPhotos' tag in Alice's PoCo service.

    The basic flow is that Alice sends Bob the link for the protected vacation photos. Bob clicks on the link and is taken to the photo service via his browser. The photo service check with the AM to determine whether the resource is protected or not. Since the resource is protected, the photo service asks Bob to authenticate. Based on Bob's authentication, and his membership in Alice's 'VacationPhotos' group, Bob is given access to the photos.

    The interesting twist with this particular use case is that the "Consumer" is really a user (i.e. Bob) who wants to view Alice's vacation photos. So when Bob tries to access the vacation photos resource that Alice shared with him, he accesses the service provider directly. At this point the SP checks with the AM regarding the authorization rules for the resource. However, Bob doesn't have a Consumer "token and secret" with which to sign his request to the SP. Instead he is accessing the SP directly via his user-agent. What Bob can do is authenticate himself to the SP using some authentication means. This is necessary as an identifier is required to determine membership in Alice's 'VacationPhotos' group.

    This leads to the question of who should manage the relationship with Alice's PoCo service to do the "membership" check? I can see two options...

    1. The AM maintains the authorization requirement (e.g. consumer must be member of Alice's VacationPhotos group) but the SP does the actual membership check. In this model the SP needs to set up a ProtectServ based relationship with Alice's PoCo service. Then when the SP authenticates Bob and has an identifier for him, it can check directly with the PoCo service determining membership based on the "contract" received from AM. This means that the SP must be able to interpret and process the "contract" on behalf of AM.

    2. The AM maintains the authorization requirement and also does the membership check with the PoCo service. In this model, the SP will need to forward Bob's identifier to the AM in order for the AM to perform the "membership" check and determine the state of the authorization. Or the SP could redirect Bob to the AM but I would that such a UX would most likely confuse the user. I do think there is a interesting privacy question on whether the SP should be allowed to forward Bob's identifier to the AM without Bob's consent.


    I'm not sure which method I like better. Maybe others have better solutions. Thoughts?
    ~1 year on
    Identity in Practice
Next page