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

Re: [rest-discuss] RESTful authorization

Expand Messages
  • Lucas Gonze
    ... I think you can reset the credentials by sending a request which causes the server to stop accepting the current credentials. That s just an idea, though
    Message 1 of 24 , Sep 22, 2005
    • 0 Attachment
      wanderingstan wrote:

      >Hi,
      >
      >Forgive me is this is a standard newbie question...
      >
      >I'm developing a firefox extension that talks with a server via a
      >RESTful API. Most REST discussions recommend using HTTP Auth (RFC
      >2617), but this solution isn't ideal because browsers keep the
      >authorization creditials until the browser is closed. This rules out
      >having multiple users on the same machine.
      >
      >Is there a workaround to this?
      >
      >
      I think you can reset the credentials by sending a request which causes
      the server to stop accepting the current credentials. That's just an
      idea, though -- I haven't tried it out.


      >Or, how terrible is it if I pass the username and password as part of
      >the URI? Everything is going over SSL, so it's not a security concern.
      >
      >
      Pretty terrible, because it breaks bookmarking, and because users will
      send URLs around that include their username and password. If HTTP auth
      doesn't work for you, a cookie-based approach is next best.

      Good luck.

      - Lucas
    • Tyler Close
      Hi Stan, Lucas, ... It s important to understand why this is terrible, because there s a very elegant solution hidden underneath the terrible. Including the
      Message 2 of 24 , Sep 23, 2005
      • 0 Attachment
        Hi Stan, Lucas,

        On 9/22/05, Lucas Gonze <lgonze@...> wrote:
        > wanderingstan wrote:
        > >Or, how terrible is it if I pass the username and password as part of
        > >the URI? Everything is going over SSL, so it's not a security concern.
        > >
        > Pretty terrible, because it breaks bookmarking, and because users will
        > send URLs around that include their username and password.

        It's important to understand why this is terrible, because there's a
        very elegant solution hidden underneath the terrible.

        Including the username and password in the URL is terrible because
        passing such a URL between users means delegating all of the sender's
        authority to the receiver. For example, I may wish to send Lucas a
        reference to a particular page I have access to. It's very surprising
        if doing so results in Lucas getting access to all of the pages I have
        access to. I only intended to provide him with access to the one page,
        and yet he received access to all of them. Passing around all of a
        user's authority in this way is a shortcut to terrible things.

        However, bundling designation and authorization in this way doesn't
        have to be a terrible thing, it can be a beautiful thing. The trick is
        to first turn your access control model on its head. Instead of
        associating authority with users, associate it with resources. Instead
        of having a password for each user, have a password for each resource.
        The user's authority is then respresented not by a single, unique
        password, but by a collection of possibly shared passwords, one for
        each resource that the user has access to. These resource passwords
        can then be safely embedded in the URLs that refer to the resource.
        Now, when a user sends another a reference to a particular page, the
        receiver gets access only to the referenced page, not all of the
        sender's pages. The mechanism now accurately reflects the sender's
        intentions, and so is not surprising.

        If all of this is a little theoretical, you can make it more concrete
        by playing with an online web-app that makes use of these concepts.
        The application is running at:

        https://yurl.net/id/home

        The home page contains a description of the application and some short
        instructions on how to use it. The application should be fairly
        discoverable even without the instructions. The short description is
        that it's an access-controlled wiki. I think this application is an
        excellent example of a RESTful, access controlled application.

        Tyler

        PS

        The above link only works well in browsers that support XSLT, such as
        IE and Firefox. Safari's support for XSLT is still incomplete. Opera's
        is non-existent. For the best experience, I recommend using Firefox.

        --
        The web-calculus is the union of REST and capability-based security:
        http://www.waterken.com/dev/Web/

        Name your trusted sites to distinguish them from phishing sites.
        https://addons.mozilla.org/extensions/moreinfo.php?id=957
      • Andrzej Jan Taramina
        ... Unfortunately, human nature will likely kill your idea as it has in almost all applications for years now. Users have trouble remembering a single
        Message 3 of 24 , Sep 24, 2005
        • 0 Attachment
          Tyler suggests:

          > Instead of having a password for each user, have a password for each
          > resource.

          Unfortunately, human nature will likely kill your idea as it has in almost
          all applications for years now. Users have trouble remembering a single
          password, and only do so easily by using a common one across all apps, which
          begs the question of how secure that is. The post-it note on the monitor or
          under the keyboard is a symptom of this issue.

          There is no way you'll get users to remember a different password for every
          resource in a restful system.

          Just MNSHO.



          Andrzej Jan Taramina
          Chaeron Corporation: Enterprise System Solutions
          http://www.chaeron.com
        • Tyler Close
          Hi Andrzej, ... (snip) ... Fortunately, they don t need to. Each resource password is embedded in the corresponding URL. The user just clicks on hyperlinks,
          Message 4 of 24 , Sep 24, 2005
          • 0 Attachment
            Hi Andrzej,

            On 9/24/05, Andrzej Jan Taramina <andrzej@...> wrote:
            > Tyler suggests:
            >
            > > Instead of having a password for each user, have a password for each
            > > resource.
            >

            (snip)

            > There is no way you'll get users to remember a different password for every
            > resource in a restful system.

            Fortunately, they don't need to. Each resource password is embedded in
            the corresponding URL. The user just clicks on hyperlinks, without
            ever needing to be aware of the resource password.

            Try using the example application at:

            https://yurl.net/id/home

            Tyler

            --
            The web-calculus is the union of REST and capability-based security:
            http://www.waterken.com/dev/Web/

            Name your trusted sites to distinguish them from phishing sites.
            https://addons.mozilla.org/extensions/moreinfo.php?id=957
          • Bob Haugen
            Tyler, Could you please explain how embedded hyperlinks work in Yurl or web-calculus? Take the case where I give you the Yurl for a Web resource where the
            Message 5 of 24 , Sep 24, 2005
            • 0 Attachment
              Tyler,

              Could you please explain how embedded hyperlinks work in Yurl or web-calculus?

              Take the case where I give you the Yurl for a Web resource where the
              representation includes hyperlinks for other resources.

              I might want you to be able GET representations from some of those
              hyperlinks, edit and PUT some of the others, POST to still others, and
              some of them I don't even want you to see. I mean, I might want
              others to be able to see them, but not you.

              I might want others to be able to get representations of the same
              resource including a different subset of the hyperlinks the resource
              knows about, with a different set of capabilities, maybe more or less
              than what I gave you.

              I think I can probably figure this out, but it's nice to get it from the source.

              Thanks,
              Bob Haugen
            • Tyler Close
              Hi Bob, ... When using capability URLs, such as in the web-calculus, your hypermedia web embodies not only your application state, but also your access policy.
              Message 6 of 24 , Sep 26, 2005
              • 0 Attachment
                Hi Bob,

                On 9/24/05, Bob Haugen <bob.haugen@...> wrote:
                > Could you please explain how embedded hyperlinks work in Yurl or web-calculus?

                When using capability URLs, such as in the web-calculus, your
                hypermedia web embodies not only your application state, but also your
                access policy. A capability URL embedded within a representation is
                authority that should always be granted when authority to the
                representation's resource has been granted.

                > Take the case where I give you the Yurl for a Web resource where the
                > representation includes hyperlinks for other resources.

                Passing a URL to another user grants that user access to the target
                resource, as well as access to any resources that are referenced in a
                fetched representation, and so on, recursively.

                For example, consider the capability URL:

                https://yurl.net/id/6fo4lr6it4topf5rqcnml2fpav2hzmug

                The above URL refers to a wiki page editor resource. A GET operation
                on this URL returns:

                <?xml version="1.0" encoding="UTF-8"?>
                <?xml-stylesheet type="text/xsl" href="/xsl/http/yurl.org/Author.xsl"?>

                <list>
                <doc schema="http://waterken.org/name/AuthorProxyScope$Author-interface">
                <super schema="http://yurl.org/Author">
                <self schema="http://web-calculus.org/pointer/Embed">
                <target>6fo4lr6it4topf5rqcnml2fpav2hzmug</target>
                </self>
                <topic>home comments</topic>
                <value schema="http://web-calculus.org/pointer/Link">
                <target>scdexb3ncrpdfp7lvd4guthvt6floqny</target>
                </value>
                <assign schema="http://web-calculus.org/pointer/Link">
                <target>puqjiq25fjqre67paoc7omi3iynbdw62</target>
                </assign>
                <revoke schema="http://web-calculus.org/pointer/Link">
                <target>mzkuol4e6u4konlco4tfxgyajqg5ewhd</target>
                </revoke>
                <proxy schema="http://web-calculus.org/pointer/Link">
                <target>z7b4euktmhbxbfax5nvvt7wsnclnjvhj</target>
                </proxy>
                </super>
                </doc>
                </list>

                The above representation contains a number of embedded capability
                URLs, including the authority to: read the current wiki text (the
                value element); assign new wiki text (the assign element); and so on.
                All of the embedded authorities are described by the schema at:
                <http://yurl.org/Author>.

                To edit a wiki page, the user naturally requires the authority to read
                the current text and the authority to assign new text. To implement
                this access policy, the hypermedia resource web is constructed so that
                both these authorities are reachable from the page editor resource.

                > I might want you to be able GET representations from some of those
                > hyperlinks, edit and PUT some of the others, POST to still others, and
                > some of them I don't even want you to see. I mean, I might want
                > others to be able to see them, but not you.

                Your hypermedia web must be designed to implement this access policy.
                Creating a hypermedia web that is at odds with your access policy puts
                you in a pickle.

                When designing your application, first start out with pencil and paper
                and draw your hypermedia web. Make sure that starting from any point
                in the web, you can only get to other points in the web that conform
                to your access policy.

                > I might want others to be able to get representations of the same
                > resource including a different subset of the hyperlinks the resource
                > knows about, with a different set of capabilities, maybe more or less
                > than what I gave you.

                I avoid such designs. I make the resource mean the same thing to all
                people, and represent extra authorities as separate resources. For
                example, my wiki home page is at:

                https://yurl.net/id/home

                I have the authority to edit that page and you don't; however, when I
                do a GET on the above URL, I see the same thing that you do. I have a
                separate URL that I use for editing the page.

                Thanks for the questions,

                Tyler

                --
                The web-calculus is the union of REST and capability-based security:
                http://www.waterken.com/dev/Web/

                Name your trusted sites to distinguish them from phishing sites.
                https://addons.mozilla.org/extensions/moreinfo.php?id=957
              • Hugh Winkler
                Tyler, tell me if I understand correctly. Seems like this is a security by obscurity approach? I would not ordinarily be able to guess the embedded url
                Message 7 of 24 , Sep 26, 2005
                • 0 Attachment
                  Tyler, tell me if I understand correctly. Seems like this is a security by
                  obscurity approach? I would not ordinarily be able to guess the embedded url
                  https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62 , but your form
                  delivers it to me, so therefore I have access to it and its descendants.

                  > <list>
                  > <doc schema="http://waterken.org/name/AuthorProxyScope$Author-interface">
                  > <super schema="http://yurl.org/Author">
                  > <self schema="http://web-calculus.org/pointer/Embed">
                  > <target>6fo4lr6it4topf5rqcnml2fpav2hzmug</target>
                  > </self>
                  > <topic>home comments</topic>
                  > <value schema="http://web-calculus.org/pointer/Link">
                  > <target>scdexb3ncrpdfp7lvd4guthvt6floqny</target>
                  > </value>
                  > <assign schema="http://web-calculus.org/pointer/Link">
                  > <target>puqjiq25fjqre67paoc7omi3iynbdw62</target>
                  > </assign>
                  > <revoke schema="http://web-calculus.org/pointer/Link">
                  > <target>mzkuol4e6u4konlco4tfxgyajqg5ewhd</target>
                  > </revoke>
                  > <proxy schema="http://web-calculus.org/pointer/Link">
                  > <target>z7b4euktmhbxbfax5nvvt7wsnclnjvhj</target>
                  > </proxy>
                  > </super>
                  > </doc>
                  > </list>
                  >

                  [hvw] The point being I had to discover the nested url
                  https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62. Nothing prevents me
                  from posting that URL on some web page, or sending it in an email to my
                  friends, right? So once you have shown me an URL, anyone I choose to send it
                  to has access too?

                  Hugh
                • Tyler Close
                  Hi Hugh, ... You correctly understand the mechanism, but label it incorrectly with security by obscurity . The embedded URL
                  Message 8 of 24 , Sep 26, 2005
                  • 0 Attachment
                    Hi Hugh,

                    On 9/26/05, Hugh Winkler <hughw@...> wrote:
                    > Tyler, tell me if I understand correctly. Seems like this is a security by
                    > obscurity approach? I would not ordinarily be able to guess the embedded url
                    > https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62 , but your form
                    > delivers it to me, so therefore I have access to it and its descendants.

                    You correctly understand the mechanism, but label it incorrectly with
                    "security by obscurity".

                    The embedded URL
                    <https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62> is unguessable.
                    The only way for you to come into possession of this URL is through
                    someone else who knows it voluntarily giving it to you. In this case,
                    I voluntarily gave you the URL
                    <https://yurl.net/id/6fo4lr6it4topf5rqcnml2fpav2hzmug>, which in turn
                    voluntarily gave you the URL
                    <https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62>. Without my
                    explicit, voluntary action, you would be unable to access the
                    identified resource.

                    "Security through obscurity" refers to mechanisms whose security
                    relies on the secrecy of a guessable secret. These mechanisms rely on
                    lack of popularity, or obscurity, reducing the chances of someone
                    bothering to make some good guesses. Such mechanisms fail when a good
                    guesser takes an interest in them, thus ending their obscurity and
                    security.

                    The random number included in a capability URL is long enough to be
                    unguessable. It doesn't matter how much attention is directed at
                    guessing such a URL, the mechanism remains secure. This approach to
                    creating security is similar to that used in SSL. The symmetric
                    session encryption key is also just a long random number. The security
                    of the SSL session depends on this long random number being
                    unguessable.

                    > > <list>
                    > > <doc schema="http://waterken.org/name/AuthorProxyScope$Author-interface">
                    > > <super schema="http://yurl.org/Author">
                    > > <self schema="http://web-calculus.org/pointer/Embed">
                    > > <target>6fo4lr6it4topf5rqcnml2fpav2hzmug</target>
                    > > </self>
                    > > <topic>home comments</topic>
                    > > <value schema="http://web-calculus.org/pointer/Link">
                    > > <target>scdexb3ncrpdfp7lvd4guthvt6floqny</target>
                    > > </value>
                    > > <assign schema="http://web-calculus.org/pointer/Link">
                    > > <target>puqjiq25fjqre67paoc7omi3iynbdw62</target>
                    > > </assign>
                    > > <revoke schema="http://web-calculus.org/pointer/Link">
                    > > <target>mzkuol4e6u4konlco4tfxgyajqg5ewhd</target>
                    > > </revoke>
                    > > <proxy schema="http://web-calculus.org/pointer/Link">
                    > > <target>z7b4euktmhbxbfax5nvvt7wsnclnjvhj</target>
                    > > </proxy>
                    > > </super>
                    > > </doc>
                    > > </list>
                    > >
                    >
                    > [hvw] The point being I had to discover the nested url
                    > https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62.

                    Exactly.

                    > Nothing prevents me
                    > from posting that URL on some web page, or sending it in an email to my
                    > friends, right?

                    Correct, as you've just demonstrated.

                    > So once you have shown me an URL, anyone I choose to send it
                    > to has access too?

                    Correct, anyone *you* *choose* to send it to has access too. This is a
                    good thing. You may have legitimate reasons for sharing your access
                    and the access control mechanism should support this. Delegating work
                    to others is often a crucial part of getting your job done.

                    Furthermore, it is impossible to prevent such delegation by you. Once
                    you have access to a resource, you could just as well setup a proxy
                    resource which accepts requests from your friends and forwards their
                    requests to the original resource. Given that I cannot prevent you
                    from setting up such a proxy service, I don't gain any access control
                    guarantees by preventing you from sharing direct access to the
                    original resource.

                    Thanks for the questions,

                    Tyler

                    --
                    The web-calculus is the union of REST and capability-based security:
                    http://www.waterken.com/dev/Web/

                    Name your trusted sites to distinguish them from phishing sites.
                    https://addons.mozilla.org/extensions/moreinfo.php?id=957
                  • Lucas Gonze
                    ... At the beginning of this conversation I couldn t have agreed less, but this explanation makes perfect sense to me. I am converted.
                    Message 9 of 24 , Sep 26, 2005
                    • 0 Attachment
                      Tyler Close wrote:

                      >The only way for you to come into possession of this URL is through
                      >someone else who knows it voluntarily giving it to you.
                      >
                      >
                      At the beginning of this conversation I couldn't have agreed less, but
                      this explanation makes perfect sense to me. I am converted.
                    • Vincent D Murphy
                      On Mon, 26 Sep 2005 14:57:39 -0500, Hugh Winkler ... This is by design. You can grant a capability to somebody by copying it. This is close
                      Message 10 of 24 , Sep 26, 2005
                      • 0 Attachment
                        On Mon, 26 Sep 2005 14:57:39 -0500, "Hugh Winkler" <hughw@...>
                        said:
                        > [hvw] The point being I had to discover the nested url
                        > https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62. Nothing prevents me
                        > from posting that URL on some web page, or sending it in an email to my
                        > friends, right? So once you have shown me an URL, anyone I choose to send
                        > it
                        > to has access too?

                        This is by design. You can grant a capability to somebody
                        by copying it. This is close to real-life keys; if I give
                        you the key to my house, you can use it even though its not
                        your house.

                        (Right, Tyler?)
                      • Hugh Winkler
                        ... [hvw] Just seems to me a lot of resource owners might want to retain the authority over who gets access to the resource. They might want me to use the
                        Message 11 of 24 , Sep 26, 2005
                        • 0 Attachment
                          >
                          > >The only way for you to come into possession of this URL is through
                          > >someone else who knows it voluntarily giving it to you.
                          > >
                          > >
                          > At the beginning of this conversation I couldn't have agreed less, but
                          > this explanation makes perfect sense to me. I am converted.
                          >

                          [hvw] Just seems to me a lot of resource owners might want to retain the
                          authority over who gets access to the resource. They might want me to use
                          the resource; they might not want me passing that authority around to
                          others. "Hugh, here is the URL for our ViewCVS... please don't show it to
                          anyone else." In that situation a legal a contract usually backs up the
                          admonition, but in the ordinary case a contract, plus some user authn/authz,
                          backs it up.


                          Hugh
                        • Hugh Winkler
                          ... [hvw] Seems like a better analogy is you leave a key in the door of the house, then you tell me where the house is.
                          Message 12 of 24 , Sep 26, 2005
                          • 0 Attachment
                            > This is by design. You can grant a capability to somebody
                            > by copying it. This is close to real-life keys; if I give
                            > you the key to my house, you can use it even though its not
                            > your house.
                            >
                            > (Right, Tyler?)
                            >
                            [hvw] Seems like a better analogy is you leave a key in the door of the
                            house, then you tell me where the house is.
                          • Lucas Gonze
                            ... It s up to resource owners to choose recipients of this capability wisely. It s not good that it is so easy for them to choose unwisely, but that s an
                            Message 13 of 24 , Sep 26, 2005
                            • 0 Attachment
                              Hugh Winkler wrote:

                              >[hvw] Just seems to me a lot of resource owners might want to retain the
                              >authority over who gets access to the resource. They might want me to use
                              >the resource; they might not want me passing that authority around to
                              >others. "Hugh, here is the URL for our ViewCVS... please don't show it to
                              >anyone else."
                              >

                              It's up to resource owners to choose recipients of this capability
                              wisely. It's not good that it is so easy for them to choose unwisely,
                              but that's an issue which can be tackled separately.
                            • Tyler Close
                              Hi Vincent, ... That s a good analogy. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your
                              Message 14 of 24 , Sep 26, 2005
                              • 0 Attachment
                                Hi Vincent,

                                On 9/26/05, Vincent D Murphy <vdm@...> wrote:
                                > On Mon, 26 Sep 2005 14:57:39 -0500, "Hugh Winkler" <hughw@...>
                                > said:
                                > > [hvw] The point being I had to discover the nested url
                                > > https://yurl.net/id/puqjiq25fjqre67paoc7omi3iynbdw62. Nothing prevents me
                                > > from posting that URL on some web page, or sending it in an email to my
                                > > friends, right? So once you have shown me an URL, anyone I choose to send
                                > > it
                                > > to has access too?
                                >
                                > This is by design. You can grant a capability to somebody
                                > by copying it. This is close to real-life keys; if I give
                                > you the key to my house, you can use it even though its not
                                > your house.
                                >
                                > (Right, Tyler?)

                                That's a good analogy.

                                Tyler

                                --
                                The web-calculus is the union of REST and capability-based security:
                                http://www.waterken.com/dev/Web/

                                Name your trusted sites to distinguish them from phishing sites.
                                https://addons.mozilla.org/extensions/moreinfo.php?id=957
                              • Tyler Close
                                Hi Hugh, ... No, the location of the house is a guessable secret. Anyone wandering down the road will come across it. The specific construction of a particular
                                Message 15 of 24 , Sep 26, 2005
                                • 0 Attachment
                                  Hi Hugh,

                                  On 9/26/05, Hugh Winkler <hughw@...> wrote:
                                  > > This is by design. You can grant a capability to somebody
                                  > > by copying it. This is close to real-life keys; if I give
                                  > > you the key to my house, you can use it even though its not
                                  > > your house.
                                  > >
                                  > > (Right, Tyler?)
                                  > >
                                  > [hvw] Seems like a better analogy is you leave a key in the door of the
                                  > house, then you tell me where the house is.

                                  No, the location of the house is a guessable secret. Anyone wandering
                                  down the road will come across it. The specific construction of a
                                  particular house key is supposed to be an unguessable secret.

                                  For example, you could go to the home page of my web site:
                                  <https://yurl.net/>. No matter how much time you spend surfing the
                                  site, or guessing site URLs, you will not discover the URL that
                                  represents the authority to edit the page at:
                                  <https://yurl.net/id/home>. That URL hasn't been left around for you
                                  to find; the key is not in the door.

                                  Tyler

                                  --
                                  The web-calculus is the union of REST and capability-based security:
                                  http://www.waterken.com/dev/Web/

                                  Name your trusted sites to distinguish them from phishing sites.
                                  https://addons.mozilla.org/extensions/moreinfo.php?id=957
                                • Tyler Close
                                  Hi Hugh, ... I could very well log all accesses to the capability URL that I give you and send you a nasty letter if I decide abusive requests have been made
                                  Message 16 of 24 , Sep 26, 2005
                                  • 0 Attachment
                                    Hi Hugh,

                                    On 9/26/05, Hugh Winkler <hughw@...> wrote:
                                    > >
                                    > > >The only way for you to come into possession of this URL is through
                                    > > >someone else who knows it voluntarily giving it to you.
                                    > > >
                                    > > >
                                    > > At the beginning of this conversation I couldn't have agreed less, but
                                    > > this explanation makes perfect sense to me. I am converted.
                                    > >
                                    >
                                    > [hvw] Just seems to me a lot of resource owners might want to retain the
                                    > authority over who gets access to the resource. They might want me to use
                                    > the resource; they might not want me passing that authority around to
                                    > others. "Hugh, here is the URL for our ViewCVS... please don't show it to
                                    > anyone else." In that situation a legal a contract usually backs up the
                                    > admonition, but in the ordinary case a contract, plus some user authn/authz,
                                    > backs it up.

                                    I could very well log all accesses to the capability URL that I give
                                    you and send you a nasty letter if I decide abusive requests have been
                                    made using that URL.

                                    I have no better recourse or investigative tools when using a
                                    username/password. You might give your username/password to someone
                                    else, so I must log all accesses and make a judgment as to whether or
                                    not the requests are abusive.

                                    In either case, I blame the person I gave the username/password, or
                                    the capability URL.

                                    Tyler

                                    --
                                    The web-calculus is the union of REST and capability-based security:
                                    http://www.waterken.com/dev/Web/

                                    Name your trusted sites to distinguish them from phishing sites.
                                    https://addons.mozilla.org/extensions/moreinfo.php?id=957
                                  • Lucas Gonze
                                    p2p-hackers, meet rest-discuss. rest-discuss, I d like to introduce you to p2p-hackers. RESTafarians: there is a long-running conversation on p2p-hackers
                                    Message 17 of 24 , Sep 26, 2005
                                    • 0 Attachment
                                      p2p-hackers, meet rest-discuss. rest-discuss, I'd like to introduce you
                                      to p2p-hackers.

                                      RESTafarians: there is a long-running conversation on p2p-hackers about
                                      friendnets, also known as darknets, small world networks, and F2F
                                      networks; also capabilities security, sometimes known as smart
                                      contracts. An example thread begins at
                                      http://zgp.org/pipermail/p2p-hackers/2005-August/002915.html

                                      p2p-hackers: Tyler Close' method for HTTP access control using nothing
                                      but unguessable (and secret) URIs came up on REST-discuss. That thread
                                      begins at http://groups.yahoo.com/group/rest-discuss/message/5228 In
                                      the context of friendnets, Tyler's scheme is a beautifully simple way of
                                      controlling access using nothing but low-tech means. Not only does it
                                      limit access to trusted parties, it also allows for transitive
                                      relationships. (Warning: his scheme is counterintuitive, since the
                                      dependence on secret URLs smells like security through obscurity).

                                      I don't mean to create a permathread out of out of this cc:list, rather
                                      to refer interested rest-discuss people to p2p-hackers and vice versa.
                                      If you reply to this, please choose one list or the other as the
                                      recipient.

                                      I've always been surprised that the intersection of REST and
                                      capabilities isn't a common theme, since both REST and capabilities
                                      revolve around precisely defined relationships. The success of defining
                                      HTTP methods in terms of privileges is due, I believe, to the way that
                                      it reflects the same underlying truth that capabilities formalize.
                                    • Hugh Winkler
                                      ... [hvw] I would have to have malicious intent, if I were to send along my password to someone. Whereas lots of security compromises could be accidental. I
                                      Message 18 of 24 , Sep 26, 2005
                                      • 0 Attachment
                                        >
                                        > I could very well log all accesses to the capability URL that I give
                                        > you and send you a nasty letter if I decide abusive requests have been
                                        > made using that URL.
                                        >
                                        > I have no better recourse or investigative tools when using a
                                        > username/password. You might give your username/password to someone
                                        > else, so I must log all accesses and make a judgment as to whether or
                                        > not the requests are abusive.
                                        >

                                        [hvw] I would have to have malicious intent, if I were to send along my
                                        password to someone.

                                        Whereas lots of security compromises could be accidental. I want my friend
                                        Jim to have your email address, so I forward him the last mail you sent me.
                                        Unfortunately that mail contains the ViewCVS url with the crown jewels. If
                                        the resource were protected by username/password, Jim could not access it.
                                        As a resource owner, I would want to at least require a deliberate,
                                        malicious action, to compromise my resource -- not a casual one, like
                                        copying a link.


                                        I appreciate the simplicity of this scheme, and it's probably appropriate
                                        where the crown jewels aren't involved!


                                        Hugh
                                      • Lucas Gonze
                                        ... You are not a good bet for such a scheme, then. That issue will resolve itself as part of the normal flow of capabilities. For example, the same problem
                                        Message 19 of 24 , Sep 26, 2005
                                        • 0 Attachment
                                          Hugh Winkler wrote:

                                          >Whereas lots of security compromises could be accidental. I want my friend
                                          >Jim to have your email address, so I forward him the last mail you sent me.
                                          >Unfortunately that mail contains the ViewCVS url with the crown jewels.
                                          >

                                          You are not a good bet for such a scheme, then. That issue will resolve
                                          itself as part of the normal flow of capabilities.

                                          For example, the same problem would crop up if the email in question had
                                          username/password in it, and even then some people will choose to
                                          forward the email.

                                          - Lucas
                                        • Tyler Close
                                          Hi Hugh, ... Not necessarily... ... That email might also contain your username/password. After all, the password must be sent to you some way. For example, if
                                          Message 20 of 24 , Sep 26, 2005
                                          • 0 Attachment
                                            Hi Hugh,

                                            On 9/26/05, Hugh Winkler <hughw@...> wrote:
                                            > >
                                            > > I could very well log all accesses to the capability URL that I give
                                            > > you and send you a nasty letter if I decide abusive requests have been
                                            > > made using that URL.
                                            > >
                                            > > I have no better recourse or investigative tools when using a
                                            > > username/password. You might give your username/password to someone
                                            > > else, so I must log all accesses and make a judgment as to whether or
                                            > > not the requests are abusive.
                                            > >
                                            >
                                            > [hvw] I would have to have malicious intent, if I were to send along my
                                            > password to someone.

                                            Not necessarily...

                                            > Whereas lots of security compromises could be accidental. I want my friend
                                            > Jim to have your email address, so I forward him the last mail you sent me.
                                            > Unfortunately that mail contains the ViewCVS url with the crown jewels. If
                                            > the resource were protected by username/password, Jim could not access it.

                                            That email might also contain your username/password. After all, the
                                            password must be sent to you some way.

                                            For example, if you open an account with mozdev.org, the project
                                            approval and introduction email will include various relevant URLs for
                                            your project (such as the mailing list), in addition to your
                                            username/password for controlling these resources.

                                            > As a resource owner, I would want to at least require a deliberate,
                                            > malicious action, to compromise my resource

                                            Absolutely, so transmit a capability URL using a mechanism that you
                                            would use to transmit a password of equivalent value.

                                            For example, a more valuable password or capability URL would be
                                            better transmitted using a PGP encrypted email.

                                            > -- not a casual one, like copying a link.

                                            The implications of doing this can be made more obvious by controlling
                                            where the link can be copied from. For example, a PGP encrypted email
                                            explaining the purpose and use of the link.

                                            > I appreciate the simplicity of this scheme, and it's probably appropriate
                                            > where the crown jewels aren't involved!

                                            Which is mostly what we use the Internet for.

                                            Applications involving the crown jewels are by definition more
                                            demanding. Our existing applications (email clients, web browsers)
                                            aren't well suited to working with high value authorities. A lot more
                                            could and should be done to improve this infrastructure.

                                            In building such infrastructure, I would build on capability URLs, not
                                            username/password. There are engineering issues to be tackled in
                                            making better software based on capability URLs, but there are
                                            semantic problems with username/password.

                                            Username/password schemes suffer from cross-site authorization issues.
                                            For example, consider a resource at my bank which will perform a spend
                                            when sent a POST with the expected HTTP Auth credentials. This
                                            resource may be located at <https://bank/account/pay>. Imagine I log
                                            into my bank account, check on some pending transactions and then go
                                            visit some interesting blogs. At the end of a blog post is a form
                                            submission button that claims to create a blog post comment. The form
                                            actually points to <https://bank/account/pay> and does a spend when I
                                            click on it. I click on the button, and my browser does the form POST,
                                            happily responding to the bank's HTTP Auth challenge using it's cached
                                            copy of my password. The spend goes through as it was sent from my
                                            machine, using my password.

                                            Access control list (ACL) based mechanisms don't work in applications
                                            where there is communication between users. Capability-based
                                            mechanisms can work.

                                            Tyler

                                            --
                                            The web-calculus is the union of REST and capability-based security:
                                            http://www.waterken.com/dev/Web/

                                            Name your trusted sites to distinguish them from phishing sites.
                                            https://addons.mozilla.org/extensions/moreinfo.php?id=957
                                          • Bob Haugen
                                            ... Ok, so I might have a logical resource that knows about lots of other logical resources , but my YURL design might need to have many capability-based
                                            Message 21 of 24 , Sep 27, 2005
                                            • 0 Attachment
                                              > On 9/24/05, Bob Haugen <bob.haugen@...> wrote:
                                              > > I might want others to be able to get representations of the same
                                              > > resource including a different subset of the hyperlinks the resource
                                              > > knows about, with a different set of capabilities, maybe more or less
                                              > > than what I gave you.

                                              On 9/26/05, Tyler Close <tyler.close@...> replied:
                                              > I avoid such designs. I make the resource mean the same thing to all
                                              > people, and represent extra authorities as separate resources. For
                                              > example, my wiki home page is at:
                                              >
                                              > https://yurl.net/id/home
                                              >
                                              > I have the authority to edit that page and you don't; however, when I
                                              > do a GET on the above URL, I see the same thing that you do. I have a
                                              > separate URL that I use for editing the page.

                                              Ok, so I might have a logical "resource" that knows about lots of
                                              other logical "resources", but my YURL design might need to have many
                                              capability-based resources for each logical "resource".

                                              For example, if my logical resource was a Purchase Order, it might be
                                              logically linked to my supplier's Sales Order, which might be
                                              logically linked to my supplier's manufacturing schedule, which might
                                              be logically linked to my supplier's suppliers, etc. I might have
                                              capability YURLs for the Sales Order but probably not all the way back
                                              to my supplier's suppliers.

                                              So the capability or YURL design would be a major upfront project
                                              phase for any new Web system. I can see this becoming a big
                                              bottleneck, full of pitfalls and errors from lack of foresight,
                                              understanding, wrong guesses as to future requirements, etc. We're
                                              back in waterfall territory, which has proven to be a bad way to
                                              develop software.

                                              What do you think?
                                            • Laurian Gridinoc
                                              ... You have to prompt the user again, for example you have an logout URI, with the same realm (browsers cache user/pass associated with the realm) and there
                                              Message 22 of 24 , Sep 28, 2005
                                              • 0 Attachment
                                                On 9/23/05, Lucas Gonze <lgonze@...> wrote:
                                                > >I'm developing a firefox extension that talks with a server via a
                                                > >RESTful API. Most REST discussions recommend using HTTP Auth (RFC
                                                > >2617), but this solution isn't ideal because browsers keep the
                                                > >authorization creditials until the browser is closed. This rules out
                                                > >having multiple users on the same machine.
                                                > >Is there a workaround to this?
                                                > I think you can reset the credentials by sending a request which causes
                                                > the server to stop accepting the current credentials. That's just an
                                                > idea, though -- I haven't tried it out.

                                                You have to prompt the user again, for example you have an logout URI,
                                                with the same realm (browsers cache user/pass associated with the
                                                realm) and there the you won't accept the user credentials, and if the
                                                user hits cancel, the authentication will be cleared.

                                                Mozilla has an extension for logging out:
                                                http://extensionroom.mozdev.org/more-info/clearhttpauth

                                                Cheers,
                                                --
                                                Laurian Gridinoc, www.grapefruit.ro
                                              Your message has been successfully submitted and would be delivered to recipients shortly.