Loading ...
Sorry, an error occurred while loading the content.

unrestful OpenId attribute exchange draft ?

Expand Messages
  • Henry Story
    I was just looking through the OpenId specs [1] and came across the attribute exchange draft [2], which is a way as I understand it of getting and setting
    Message 1 of 3 , Jul 26, 2007
    View Source
    • 0 Attachment
      I was just looking through the OpenId specs [1] and came across the
      attribute exchange draft [2], which is a way as I understand it of
      getting and setting property value pairs for describing people
      associated with an OpenID.

      Though I like OpenId for its nice Resource Oriented Architecture, I
      was a bit concerned about that draft. It is really not doing things
      right, I think.

      Here are some of the faults I found with it (see comment in [1]):

      (1) It ties the identity provider to the identity. The nice thing
      about OpenId, is that it separates the role of the identity provider
      and the identity. This allows one to have an id (I could use http://
      bblfish.net/) and change identity provider over time, as I change job
      for example, or even have a number of different ones at the same
      time. The OpenId attribute exchange is overloading the identity
      provider (which is really an identity verifier) functionality
      relating to identity description.

      (2) It does not feel RESTful. If something is to return information
      it should have a URL. Here there is very clearly overlapping of
      concerns as explained above. What is the url for information for one
      identity here? I have a large alarm bell ringing when I read sections
      such as: "Fetch message" and "store message". Is that not the
      equivalent of HTTP GET and PUT?

      (3) duplicating effort. This spec is inventing a metadata format, a
      query language and storage API, which is a lot of work. These things
      have been done before:

      -a- metadata framework: as shown above RDF does this very well
      already. It has a very powerful semantics, has gone through years of
      review by some of the best thinkers in the world, is extensible, self
      describing, etc, etc... having to learn another special convention
      as proposed here, is one more unnecessary piece of work.

      -b- query language: SPARQL though not yet finished does
      everything that is needed here as shown in the example given at [1]

      -c- storage: this could be done using a number of well known
      technologies, such as ftp, scp, Atom Protocol, or even WebDav. AtomP
      and WebDav are even nicely RESTful.

      It kind of shows I think how one has to be careful not to accept the
      work of one group as good of the bat, just because they did excellent
      work before hand. Am I being unjust?

      Henry

      PS. Now criticism (1) above is a little tricky perhaps because if
      the Identity Provider has no say
      over the OpenId resource, and that is used to point to personal
      information, then the open id could be describing itself in ways that
      would be completely unacceptable to the organisation controlling the
      Identity Provider. So there may be a good reason to have it have some
      control over the OpenId, or for one to want to ask it questions
      regarding the identity of the person associated with that id.

      In my view what will happen is that in the end all identity providers
      will have control of their openid they give out. So as Sun gives out
      http://openid.sun.com/bblfish so visa will give out
      http://visa.com/iod/1231341 and there will then be my personal openid
      foaf file, which will link them all together (if I want to).



      [1] http://blogs.sun.com/bblfish/entry/foaf_openid
      [2] http://openid.net/specs/openid-attribute-exchange-1_0-05.html


      Home page: http://bblfish.net/
      Sun Blog: http://blogs.sun.com/bblfish/
      Foaf name: http://bblfish.net/people/henry/card#me
    • Norman Gray
      Henry, hello. ... Disclaimer: I ve looked through the attribute exchange draft, but haven t studied it; the following is not, I think, dependent on the fine
      Message 2 of 3 , Jul 26, 2007
      View Source
      • 0 Attachment
        Henry, hello.

        On 26 Jul 2007, at 15:32, Henry Story wrote:

        > (2) It does not feel RESTful. If something is to return information
        > it should have a URL. Here there is very clearly overlapping of
        > concerns as explained above. What is the url for information for one
        > identity here? I have a large alarm bell ringing when I read sections
        > such as: "Fetch message" and "store message". Is that not the
        > equivalent of HTTP GET and PUT?

        > -b- query language: SPARQL though not yet finished does
        > everything that is needed here as shown in the example given at [1]

        Disclaimer: I've looked through the attribute exchange draft, but
        haven't studied it; the following is not, I think, dependent on the
        fine details.

        My feeling is that SPARQL is not a good fit here, because this might
        be a case where a RESTful approach is not ideal.

        Attribute exchange is pretty fundamentally a conversation: if I want
        to get a set of Ignatius's attributes from you, I have to assure
        myself of who you are, but you also have to either (a) assure
        yourself of who I am, and that I am permitted to get all of
        Ignatius's attributes, or (b) I have some other legitimate need to
        get this information, which fits in with a pre-existing policy:

        me: tell me Ignatius's age
        you: why do you want to know?
        me: I'll only sell him drink if he's over 18
        you: OK: he's over 18, but I'm not telling you his birthday
        me: that'll do

        When fully general, this turns into a decidedly non-trivial problem.

        The simpler case which seems to be suggested in OpenID docs and the
        attribute exchange draft, of allowing the (human) OpenID owner to
        choose on the fly what attributes are released to a relying party,
        still involves a three-way interaction, between the relying party,
        the IdP and the human. Although you can characterise that as a GET
        which might take a long while to be retrieved (when will the user
        come back from coffee?), it feels a bit forced to me. It's doable,
        but it's not clear how `this is who I am and why I want your
        birthday', or even just `this is who I am', would be included in the
        SPARQL request.

        The case which you describe in your (excellent) [1] is, I think, the
        most basic case, where all the attributes are available without any
        policy at all, and the problem is simply how does one associate
        Ignatius's FOAF file with his OpenID. Now, OpenID is about keeping
        things simple, and it might be deemed valuable to keep things
        precisely this simple; in that case, a pointer to a FOAF file would
        indeed be hugely simpler than a new protocol.

        > [1] http://blogs.sun.com/bblfish/entry/foaf_openid



        Separately:

        > PS. Now criticism (1) above is a little tricky perhaps because if
        > the Identity Provider has no say
        > over the OpenId resource, and that is used to point to personal
        > information, then the open id could be describing itself in ways that
        > would be completely unacceptable to the organisation controlling the
        > Identity Provider. So there may be a good reason to have it have some
        > control over the OpenId, or for one to want to ask it questions
        > regarding the identity of the person associated with that id.
        >
        > In my view what will happen is that in the end all identity providers
        > will have control of their openid they give out. So as Sun gives out
        > http://openid.sun.com/bblfish so visa will give out
        > http://visa.com/iod/1231341 and there will then be my personal openid
        > foaf file, which will link them all together (if I want to).

        Can you elaborate on this? Do you just mean that sun.com might not
        want openid.sun.com/bblfish to be able to say 'My politics are X'?

        My first reaction to such a prohibition would be that it
        misunderstands what (I think) OpenID is clever about. OpenID avoids
        some of X.509's problems by _not_ making any link between online and
        offline entities. So, pace Tim Bray in [a], all an OpenID says is
        that its owner is the same person over time; the IdP doesn't warrant
        that the name means anything. The IdP doesn't even warrant that the
        attributes it's supplying are true, simply that these are honestly
        what the offline human told it to say.

        Or am I missing your point?

        Best wishes,

        Norman

        [a] http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID#p-3

        --
        ------------------------------------------------------------
        Norman Gray : http://nxg.me.uk
        eurovotech.org : University of Leicester, UK
      • Story Henry
        Thanks for the feedback Norman. I am forwarding this back to the openid group, because your responses have really helped me understand the issues better. By
        Message 3 of 3 , Jul 26, 2007
        View Source
        • 0 Attachment
          Thanks for the feedback Norman. I am forwarding this back to the
          openid group, because your responses have really helped me understand
          the issues better.

          By the way there is a really useful pdf book on OpenId that is
          available for review currently, before it goes to the printer:

          http://www.openidbook.com

          On 26 Jul 2007, at 18:26, Norman Gray wrote:

          > Henry, hello.
          >
          > On 26 Jul 2007, at 15:32, Henry Story wrote:
          >
          >> (2) It does not feel RESTful. If something is to return information
          >> it should have a URL. Here there is very clearly overlapping of
          >> concerns as explained above. What is the url for information for one
          >> identity here? I have a large alarm bell ringing when I read sections
          >> such as: "Fetch message" and "store message". Is that not the
          >> equivalent of HTTP GET and PUT?
          >
          >> -b- query language: SPARQL though not yet finished does
          >> everything that is needed here as shown in the example given at [1]
          >
          > Disclaimer: I've looked through the attribute exchange draft, but
          > haven't studied it; the following is not, I think, dependent on the
          > fine details.

          Neither had I. Chapter 6 of the book I mentioned above goes over it
          in easier language.

          > My feeling is that SPARQL is not a good fit here, because this
          > might be a case where a RESTful approach is not ideal.
          >
          > Attribute exchange is pretty fundamentally a conversation: if I
          > want to get a set of Ignatius's attributes from you, I have to
          > assure myself of who you are, but you also have to either (a)
          > assure yourself of who I am, and that I am permitted to get all of
          > Ignatius's attributes, or (b) I have some other legitimate need to
          > get this information, which fits in with a pre-existing policy:
          >
          > me: tell me Ignatius's age
          > you: why do you want to know?
          > me: I'll only sell him drink if he's over 18
          > you: OK: he's over 18, but I'm not telling you his birthday
          > me: that'll do

          Hehe. That would indeed be very cool. One could I am sure do that in
          SPARQL too, but one would need a relation such as
          query:IWillAnswerOnlyIfYouAnswerThisFirst relation.


          > When fully general, this turns into a decidedly non-trivial problem.

          Indeed... Interesting idea. But I don't think that this is what they
          are proposing... as I just realized you admit below.

          > The simpler case which seems to be suggested in OpenID docs and the
          > attribute exchange draft, of allowing the (human) OpenID owner to
          > choose on the fly what attributes are released to a relying party,
          > still involves a three-way interaction, between the relying party,
          > the IdP and the human.

          Ah thanks for pointing that out. I just found that stated in the book

          "In general, any time a Consumer requests these additional parameters
          for user registration purpose, the identity provider should prompt
          the End User before sending these parameters to the Consumer. The End
          User should be given a choice which parameters it wants to send to
          the Identity Provider"

          I had not picked up on this.

          > Although you can characterise that as a GET which might take a long
          > while to be retrieved (when will the user come back from coffee?),
          > it feels a bit forced to me. It's doable, but it's not clear how
          > `this is who I am and why I want your birthday', or even just `this
          > is who I am', would be included in the SPARQL request.
          >

          Well I think one could look at this as a form of indirect SELECT
          SPARQL query where the
          variables in the SELECT get to be chosen by the end user. Ie the
          Consumer sends

          WHERE {
          ?p foaf:openid <http://openid.sun.com/bblfish> .
          OPTIONAL { ?p foaf:birthday ?bday } .
          OPTIONAL { ?p foaf:mbox ?mbox } .
          }

          and the End User gets to prepend the SELECT clause

          SELECT ?bday

          if he only wants the birthday to be passed on but not the mbox.

          It is not done as a SPARQL request because that would make for URL
          redirects that are much too long. So really the protocol is working
          with a predefined template SPARQL query, and the
          field names are the names of the variables passed around without the
          '?'.

          Mhh looked at this way, it seems easier to understand to me, and it
          makes more sense.

          Mind you in that case it should be easy to define how to change the
          information on the server: do a PUT of some foaf there. That would
          remove the I think clearly unRESTful storage protocol. I mean clearly
          here they are reinventing HTTP response codes, with things such as
          storage success, storage failure, etc...

          Another thought: if one thinks about it, this redirect to the server
          has to happen because the end user does not have a rdf database to
          query. If he did then the client could query the user directly.

          > The case which you describe in your (excellent) [1] is, I think,
          > the most basic case, where all the attributes are available without
          > any policy at all, and the problem is simply how does one associate
          > Ignatius's FOAF file with his OpenID. Now, OpenID is about keeping
          > things simple, and it might be deemed valuable to keep things
          > precisely this simple; in that case, a pointer to a FOAF file would
          > indeed be hugely simpler than a new protocol.
          >
          >> [1] http://blogs.sun.com/bblfish/entry/foaf_openid
          >

          :-) ok happy to have contributed something.

          I had tried to deal with the problem by having the foaf file return
          more or less information. I would have required the end user specify
          what should be visible for that Client when entering his password.
          There was some hand-waving there, because it was not so clear how one
          can identify the server. One would have to:

          - give the client an OpenId too, which I was thinking could be
          linked to the server_root
          - identify the foaf file somehow as being identity dependent,
          perhaps by adding a new HTTP header pointing to the login point, so
          that the client would know to login for more information
          - and of course the foaf file would have to be served by the same
          service as the openid authentication.

          But that may in the end be more complicated than the query part of
          the protocol defined above, and does not feel as clean as the
          indirect query idea.

          It looks like the idea of querying the end user directly would be the
          best, once he has been correctly identified. In that case though the
          end user is not that different from a very slow web server.

          It would be interesting to think more about a SPARQL based service,
          given the flexibility such a language and format make available.

          > Separately:
          >
          >> PS. Now criticism (1) above is a little tricky perhaps because if
          >> the Identity Provider has no say
          >> over the OpenId resource, and that is used to point to personal
          >> information, then the open id could be describing itself in ways that
          >> would be completely unacceptable to the organisation controlling the
          >> Identity Provider. So there may be a good reason to have it have some
          >> control over the OpenId, or for one to want to ask it questions
          >> regarding the identity of the person associated with that id.
          >>
          >> In my view what will happen is that in the end all identity providers
          >> will have control of their openid they give out. So as Sun gives out
          >> http://openid.sun.com/bblfish so visa will give out
          >> http://visa.com/iod/1231341 and there will then be my personal openid
          >> foaf file, which will link them all together (if I want to).
          >
          > Can you elaborate on this? Do you just mean that sun.com might not
          > want openid.sun.com/bblfish to be able to say 'My politics are X'?

          No but I suppose they might not want it to say "My name is Jonathan
          Schwartz" :-)

          > My first reaction to such a prohibition would be that it
          > misunderstands what (I think) OpenID is clever about. OpenID
          > avoids some of X.509's problems by _not_ making any link between
          > online and offline entities. So, pace Tim Bray in [a], all an
          > OpenID says is that its owner is the same person over time; the IdP
          > doesn't warrant that the name means anything. The IdP doesn't even
          > warrant that the attributes it's supplying are true, simply that
          > these are honestly what the offline human told it to say.

          That is a good response. And so having the OpenId be a FoafDocument,
          or point to a FoafDocument that is outside of the sphere of influence
          of the Identity Provider is ok. As OpenId is specified currently.

          But!

          Sun stated that all OpenIds starting with http://blogs.sun.com/
          bblfish identify Sun employees. They have had to do that verbally
          since OpenId by itself does not make any tools available to make this
          possible.

          Now in my last post I showed how Sun could make this statement with a
          few simple additional foaf relations [2], and by creating itself a
          corporate foaf file. Essentially you can think of the Identity
          Provider service as a group identifier, that can also identify the
          members of the group. This would then give a mechanical way for sun
          to make a statement about that service. The service could also make
          the same point by pointing back in a rdf/xml representation back to
          the Sun Microsystems foaf file.

          In that situation it is clear that Sun will not want the attributes
          on its service endpoint to be all equally updatable, because they are
          now making claims about the members of the Sun group, with legal
          responsibilities. Neither would Sun want the foaf file linked to from
          the openid.sun.com/bblfish to be completely in the hands of the
          employee. Some attributes may, but others may not.

          So I think I have shown in [2] that OpenId could be used for a lot
          more than what it is used for currently, with a little bit of extra
          metadata, which is neat.


          > Or am I missing your point?
          >
          > Best wishes,
          >
          > Norman
          >
          > [a] http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID#p-3
          >

          [2] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun


          > --
          > ------------------------------------------------------------
          > Norman Gray : http://nxg.me.uk
          > eurovotech.org : University of Leicester, UK
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.