Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet

Oasis Gives SAML 1.0 a Thumbs-Up 134

Posted by CowboyNeal from the new-internet-order dept.
Anonymous Custard writes "Oasis has approved the SAML 1.0 specification. From Infoworld: 'Members of the Oasis interoperability consortium approved the Security Assertion Markup Language (SAML) on Wednesday as an OASIS open standard. The move paves the way for the XML-based framework to enable secure SSO (single sign-on) and other security functions for Web services transactions spanning multiple hosted sites.' I feel more secure already!"
This discussion has been archived. No new comments can be posted.

Oasis Gives SAML 1.0 a Thumbs-Up More

Oasis Gives SAML 1.0 a Thumbs-Up

Comments Filter:

  • Passport competition? (Score:5, Interesting)

    by Alethes ( 533985 ) on Wednesday November 06, 2002 @09:23PM (#4613526)
    Is this an open standard that will compete with Passport, or is it something that Passport will have interoperablity with? Are they even related?
    • Comment removed based on user account deletion
    • This is not a Passport competitor in the regards you would think. Passport is a service and a protocol whereas SAML is only a protocol.

      Vendors and OS projects will need to build an impl of this protocol before anyone can hope to take on the Passport service as a vendor.
    • The thing that could be a possible Passport competitor is called Shibboleth:


      It is built on SAML. Read the deployment docs to get an overview (some of it's dated though).

      We've started testing the alpha where I work, it's coming along. The stuff you'll be able to do with Shib is amazing.

    • I don't know if it means much but Microsoft is a Sponsor Member [oasis-open.org].
    • In short, no.

      Passport is a centralized web based SSO system.

      SAML is a protocol/framework for exchanging security assertions. It's not possible to build Passport out of pure SAML, for one SAML lacks a single signout protocol which kind of makes the whole thing rather useless. The Liberty Alliance (who will be releasing 1.1 soon) extend SAML to bring it up to speed.

      We can basically forget about Passport interop for now. I did look into it a few weeks ago for the Identity system I'm working on, but unless Microsoft radically change things (and indications are they won't) anything more advanced than automatic logins would require their approval, you'd probably just get denied access to the network.

  • Bah. (Score:2, Insightful)

    by UndercoverBrotha ( 623615 )
    XML is slowly but surely turning into the huge beast from where it came, SGML [w3.org], I thought the point of XML was simplicity...forget the open standards of data exchange everyone is talking about, the bickering of the major players will never allow XML, or any specifications dervied from it to become the "one" format for efficient data exchange

    MSXML
    SunXML
    IBMXML

    ..get used to it, and more articles like this. [microsoft.com]

    • Re:Bah. (Score:2, Insightful)

      by Anonymous Coward
      And Xerces...

      Those are just libraries for creating/parsing XML documents. The output of ALL of them is 100% compliant XML. The programming interfaces are not specced at all and are of course 100% different in all implementations.

      I don't think you GROK what XML is exactly to have made that statement.

    • Re:Bah. (Score:5, Informative)

      by smallpaul ( 65919 ) <paul @ p r e s c o d . net> on Wednesday November 06, 2002 @09:31PM (#4613576)
      SAML is not part of XML and in no way complicates XML. SAML is a specification built on XML. But to say that SAML complicates XML would be like saying that Mozilla complicates glib.

    • Re:Bah. (Score:1, Funny)

      by Anonymous Coward
      MSXML
      SunXML
      IBMXML
      are all just XML parsers, all parse 100% pure XML and all produce 100% pure XML.
      XML is (in slashdotarian),
      thou shall use tags, like so <biggles>
      thou shall always close a started tag, like so </biggles>
      thou shall use DTD's

      People can then use XML to make standards based on that, and as long as the DTD/Scheame and notes on the DTD are aviable anything with an XML parse can use it.
    • Comment removed based on user account deletion

      • Re:Bah. (Score:3, Informative)

        by Zeinfeld ( 263942 )
        Seriouly, Has anyone heard of lex and yacc these days?

        Yes, of course I have. But I do not believe that LR(1) grammars as constructed by yacc have any place in a computer language. Chmosky's syntax theories are designed to model human languages. A computer language that requires the power of a full LR(1) parser is almost certainly more complex than it needs to be.

        lex involves processing that is only slightly simpler than yacc. Again regular expressions are great theory but using the unconstrained power of lex tends to result in specifications that are much more complex to parse than they need to be.

        lex and yacc are tools for building compilers. A (non validating) xml parser can be constructed by hand without much difficulty.

        Incidentally SAML does not use DTDs. In my view DTDs are an obsolete anacronism. SAML is specified using XML Schema which supports a full object oriented data model. XML Schema is unfortunately something of a beast, an XML Schema actually defines two type systems, not just one. An XML element definition defines a type of an element instance. An XML type definition actually specifies the type of a type.

        Even so it is much simpler to use XML to define the data structures and then use automated toold to generate the serialization and parsing code than it is to use yacc, unless of course you start building data models arround yacc - definitively not recommended, been there, done that.

        So don't jump to the conclusion that just because we did not choose to use a familliar tool we don't know what we are doing. I have written specifications based on LR(1) grammars, I have no intention of repeating the experience.

        • In BNF notation Java has 54 productions, C++ has 88, and XML has 89. Where Java and C++ only support a single character encoding according to their standards, XML requires support for at least 2, one of which must be supported in both endian encodings. Where LR(1) grammars define at design time the significance of whitespace, XML must parse a DTD at runtime to determine when whitespace is or is not significant. In XML arbitrary characters or data can be represented in at least two ways other than a raw character, and XML has built into it a substitution language - so its fair to compare its complexity to C++ and CPP.

          XML is a complex and difficult to implement standard (as evidenced by the very few completed, compliant parsers that are available).

          • Re:Bah. (Score:1)

            by zby ( 398682 )
            I'm a bit suprised about the complexity of XML - isn't it all about balanced parenthesis expressions?
            Don't read me wrong - I believe you that it has those 89 productions. I just state that it's suprising and perhaps the fact that it looks so simple is the reason that managers like it so mutch.

            • On the surface XML looks very simple. Balanced parenthesis expressions, as you say. Just under the surface it doubles its complexity: attributes are functionality equivalent to sub-expressions which have the limitation that they themselves can't have sub-expressions. This gives you two equivalent ways to represent information, which complicates the data model. It also makes it slightly more difficult to parse.

              But when you get to the actual syntax, all hell breaks loose. A parser must understand UTF-8 and UTF-16 encoding (the latter in big endian or little endian format).

              A parser must also parse not only the simple embedded parenthesis we know as XML, but also a DTD. Even if it cannot validate, it must parse the DTD in order to get past it and parse the rest of the document, in order to substitute entities, and in order to handle whitespace correctly.

              Beyond the DTD and "basic XML syntax", it must handle special cases for comments, CDATA sections and processing instructions. All of these are effectively subgrammars - once you enter the section it has its own completely different rules for how its content is (or is not) parsed.

              The parser must also detect and substitute entities, as specified in the DTD. The DTD also determines where whitespace is and is not significant, and therefore whether the parser must or should ignore whitespace, or must report it to the application (which is using the parser).

              XML looks simple, and simple non-compliant XML parsers that parse simple XML are easy to write and in abundance. But XML, complete, is complex and tricky.

              • Re:Bah. (Score:2)

                by Axe ( 11122 )
                But when you get to the actual syntax, all hell breaks loose. A parser must understand UTF-8 and UTF-16 encoding (the latter in big endian or little endian format).

                Apparently, you do not give a flying fuck about people who do not use American English and ASCII encoding.
                Well, the majority of world population does care about these issues and uses different character sets. If it means a bit more trouble for american programmers - I would say, fuck them lazy fucks.

                Of course - if you ever had to fit in internationalization support into your wondercode, starting on yacc and proceeding into char* haven, then you frigging deserve it.

                I would rather have the toolkit writer have a few grey hairs..

                • Actually, I do. Like most sane people I understand that one unicode character encoding (EITHER UTF-8 OR UTF-16LE OR UTF-16BE OR UTF-32 OR on of the many others) is adequate. UTF-8 gives you a nice advantage of compatibility with the ASCII-7 character set, which means widespread support for text editing.

              • Does the parser really needs to understand the encoding? I mean all the syntax important characters are from the ascii range - so they have the same encoding in all of them. The difference in encoding is importand to semantics but not to syntax.

                • The syntax characters are not the same in all encodings. This is made completely clear by one of the appendices to the XML specification, which explains how a parser can determine the character encoding in use by examining the first four bytes of the file.

                  Since an XML document must start with <?xml, in UTF-8 the first four bytes will be <?xm . In UTF-16, however, the fist four bytes will contain BE or LE 16-bit encodings for just the first two characters <?, because each character uses at least 16-bits to encode. You can also determine UTF-32 encodings and others.

                  Encoding determines how to interpret the bits and bytes of the document into characters, and the control characters are not the same in all encodings. A parser that naively parses a document as ASCII will get the completely wrong idea if it is UTF-8 encoded, where there may be multiple bytes per character. A UTF-16 encoded document parsed as UTF-8 will be completely garbled.

    • I thought the point of XML was simplicity

      The point of XML was to allow subset languages to be created for the efficient exchange and storage of data, in a logical (human-readable) format.

      SAML is defined using XML. It changes nothing in XML. How exactly does this bring XML any closer to becoming SGML?

      That your uninformed post got +4 amazes me, truly.
    • I'd like to join the chorus about your misconception. Besides, you sound just like my boss. You want to know all XML is?

      1. It's a text markup "language" with <begin tags> and </end tags> like html.
      2. It's tags have to have a start and end tag and are case sensitive.
      3. Start tags can have attributes in the form of attribute="value"
      4. XML documents begin with an XML version tag.

      That's it. Complex huh?

      • Plus 85 other rules. Yes, really - check the specification. There mere fact that it has attributes AND every tag can contain tags gives you two orthogonal and redundant data models. There are two character encodings, three character/data representations, four syntactically distinct data models ... and only about four parsers that can claim to be compliant or close to compliant with the specification. Yes, complex.

        • Re:Bah. (Score:2)

          by Axe ( 11122 )
          Plus 85 other rules. Yes, really - check the specification. There mere fact that it has attributes AND every tag can contain tags gives you two orthogonal and redundant data models. There are two character encodings, three character/data representations, four syntactically distinct data models ... and only about four parsers that can claim to be compliant or close to compliant with the specification. Yes, complex.

          Allow me to repeate my objection to your frigging nonsense:
          So what? Toolkit writer worries about this shit. User does not. XML is simple.

    • XML, or any specifications dervied from it to become the "one" format for efficient data exchange

      XML as it is now will never be efficient at anything. To be efficient, the XML structure would need to be represented in binary. (And there would be no loss of interoperability.) And any numeric arrays need to be represented raw.

  • Just a thought (Score:3, Interesting)

    by cranos ( 592602 ) on Wednesday November 06, 2002 @09:24PM (#4613537) Homepage Journal
    and keep in mind I am not all that up to speed with web services but are any of these XML files that are going to be used for authentication going to be encrypted?

    I can see a giant hole here in terms of a dedicated cracker intercepting un-encrypted XML files, parsing the information and then using that info for their own nefarious (yes its a big word) schemes.

    Again when it comes to Web Services I am not the most up to date, its just a thought

    • Re: (Score:3, Interesting)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

      • Re:Just a thought (Score:3, Informative)

        by Zeinfeld ( 263942 )
        Well, I'm sure the spec calls for encryption (as it would never get accepted otherwise)....

        I suspect that I am the only person on this thread who has actually read the specification.

        SAML does not 'call for' encryption. It states that if confidentiality is a requirement then some form of encryption should be used. The actual encryption services are provided by either SSL or WS-Security.

        Then again, run a sniffer on your corporate/college network, and take a look at all those fools who use IMAP and POP without ssl to get their email. It's no better.

        This statement is remarkably clueless if you bother to read what SAML does. It is a single sign on protocol (amongst other things). Protecting the confidentiality of authentication credentials is not something easily overlooked when designing such protocols, particularly when it is largely based on research work done by VeriSign and Netegrity which are both specialists in cryptographic security.

        • kudos to you for actually RTFSpec. However its a bit worrying that a spec whos entire reason for existing is cross-authentication between two or more different sets of Web Services does not make encryption part of its core.

          I will be reading the spec tonight, but as I said in my previous post in this case I believe that any sort of authentication standard has to move away from plain text across the net as its base and onto encryption.

          • kudos to you for actually RTFSpec

            Not really, I was the editor.

            However its a bit worrying that a spec whos entire reason for existing is cross-authentication between two or more different sets of Web Services does not make encryption part of its core.

            Not at all. I was working on the WS-Security specification with Microsoft and IBM at the same time as I was editing SAML. The SAML group anticipated that WS-Security would be proposed as soon as the SOAP 1.2 specification started to stabilize.

    • The spec includes a reference to a W3C Proposed Recommendation (Oct. 3, 2002) for XML Encryption Syntax and Processing [w3.org]:
      "a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data."

  • And as always (Score:3, Funny)

    by kaosrain ( 543532 ) <{root} {at} {kaosrain.com}> on Wednesday November 06, 2002 @09:24PM (#4613538) Homepage
    Pornography will be the first industry to utilize this new technology ;) -Kaos

  • An example (Score:1, Informative)

    by Call Me Black Cloud ( 616282 )
    Basically you want a site/service you've authenticated with to authenticate you with other sites, so the spec lays out how this should be done. From the RFC (just a snippet):

    <password>
    <display>*******</display>
    <actual>password</actual>
    </password>
    Simple!
    • what the heck is that semicolon ';' doing in there? It's not even inside the root tag, wouldn't that be invalid XML?

    • Re:An example (Score:5, Informative)

      by Zeinfeld ( 263942 ) on Thursday November 07, 2002 @01:15AM (#4614633) Homepage
      Basically you want a site/service you've authenticated with to authenticate you with other sites, so the spec lays out how this should be done. From the RFC (just a snippet):

      More utter clulessness, I edited the SAML specification. In the first place it is an OASIS standard, not an IETF RFC. Secondly the code fragment cited is completely bogus.

      SAML is the Security Assertion Markup Language. It allows security assertions to be specified. A security assertions consists of one or more statements, which may be subject to a number of conditions and contain additional advice.

      A SAML Authentication assertion may be used to specify that a subject has been authenticated using user name and password.

      There was a time when Karma Whores would actually read the material they were citing.

      • Look Zigfried...it's a joke. See, it's supposed to be all about security, yet the password is stored in plain text in the "sample". Didn't you like the part about "display" being a bunch of *'s?

        I thought it was funny that the post was modded informative - I think it's hilarious that you took it so serious! Here's another xml snippet for you:

        <sucka>you</sucka>
        • Look Zigfried...it's a joke. See, it's supposed to be all about security, yet the password is stored in plain text in the "sample". Didn't you like the part about "display" being a bunch of *'s?

          It might be funny if there weren't so many people on slashdot who might actually think that way,.

          It is like Ronald Reagan making a 'joke' about bombing Russia, it wasn't funny because lots of people really did think he was a senile fool who might do something like that.

  • well... (Score:1, Insightful)

    by bytes256 ( 519140 )
    security and privacy were fun while they lasted...this freakin single-sign-on crap scares me just a lil

  • In Other News... (Score:5, Funny)

    by CySurflex ( 564206 ) on Wednesday November 06, 2002 @09:47PM (#4613662)
    In Other News...

    The W3C announces the new "CONVERT everything to XML guidebook", including new XML underwear, a revised XSLT super hero, an XML car that drives you to any XPATH, XSD-SCHEMA based twinkies, and of course still supporting the girlfriend that doesn't answer any XML-QUERIES.

  • But what I really want to know is... (Score:4, Funny)

    by Myco ( 473173 ) on Wednesday November 06, 2002 @09:48PM (#4613666) Homepage
    Do they still think they're the Beatles?

  • Implementation already included in MS FrontPage (Score:5, Funny)

    by PDHoss ( 141657 ) on Wednesday November 06, 2002 @10:03PM (#4613733)
    <password noPeeking="1">
    !seineeWerAsreenignEepacsteN
    </password>
  • I think it's great that Noel has decided to venture into the computer informatics field. He can leverage off the vast experience of the Open Source developer community to craft his new offering. With their sheer brilliance, the Open Source developer community can overcome most obstacles within a matter of hours.

    Only when we realize the massive potential of Open Source, can we repair the weak Gaussian Blur filters in Photoshop.

  • I'm sorry, (Score:1, Funny)

    by Anonymous Coward
    can some one give me a simple explaination?

    Dr. Hibbert: Homer, I'm afraid you'll have to undergo a coronary bypass operation.
    Homer: Say it in English, Doc.
    Dr. Hibbert: You're going to need open-heart surgery.
    Homer: Spare me your medical mumbo-jumbo.
    Dr. Hibbert: We're going to cut you open and tinker with your ticker.
    Homer: Could you dumb it down a shade?
  • Anyone have any luck compressing SAML-encoded security assertions, or any use of XML for that matter? Maybe I'm old-fashioned, but to me having a plethora of XML tags without abbreviations of any kind is an inadequate use of the ASCII encoding character space. Which is clearer?
    D. E. Knuth,
    The art of computer programming. Vol. 2, Seminumerical algorithms, third ed., Addison-Wesley Series in Computer Science and Information Processing. Addison-Wesley, Reading, MA, 1997.
    or:
    <citation>

    <author><sirname>Knuth</sirname><givenname>Donald< /givenname><middlename>Ervin</middlename>
    <entitled>Art of Computer Programming, The</entitled>
    <volume>2<volume>
    <subtitle>Seminumerical Algorithms</subtitle>
    <edition><ordinal>3</ordinal></edition&gt ; <excerpt>Addison-Wesley Series in Computer Science and Information Processing</excerpt>
    <publisher>Addison-Wesley</publisher>
    <publishers_house>Reading, MA</publishers_house>
    <year>1997</year>
    I'm not knocking XML--but you have to admit it is extremely verbose compared to terse standard syntaxen available today. If one can combine the flexibility of XML with the tersity of unstructured documents, we'll in for a datum revolution.
    • Sure, your simple Ascii version looks simpler, but when you have to write code to grab the title or author, your code will be much longer. XML is not about saving space on the original encoding, it's about saving time each time you have to reuse that information in a different context. Stylesheets are simple to make. Parsing your simple example for the Publisher is an extremely difficult problem, when you consider that there are lots of different citation formats. With XML, I don't care which format you use, because a simple XPath expression (//author) gives me the author elements wherever they are.
    • Which is clearer?
      D. E. Knuth, The art of computer programming. Vol. 2, Seminumerical algorithms, third ed., Addison-Wesley Series in Computer Science and Information Processing. Addison-Wesley, Reading, MA, 1997.
      or:
      (xml I'm not encoding)
      To the computer? The XML... My sax parser can understand one, allowing me to map every bit of info into a program without (much) hassle. The other, I have to write a parser to take the chunks of information and stuff it into my widget.

      I use to think the same way... until I was converting cobol copybooks into C struts and/or Java. Bandwidth is cheap compared to my time, and lord knows I left some really ugly code (three companies ago) for someone to figure out why the hell I'm grabbing a few characters which map to something important in the HL7 spec.
    • Verbose, XML is. However, as storage & network bandwidth are have become very "inexpensive" commodities, the issue of bulk gets put on the sidelines, in comparison to the complexity of parsing more terse syntax. ASN.1 being an example of such an "interoperable" and "terse" syntax, which is complex enough that nobody tends to parse it right.
    • Apparently the people over at Open Office (or Star or Sun or whatever) had some luck. Their default file format is compressed XML. Usually smaller compared to binary .DOC files. You can even look at it. Try typing unzip someOO.swx

      Happy Hacking!
    • The first one may be clearer to you, but it doesn't mean a heck of a lot to your computer.
      Unless you do some fancy custom checks, your computer can't tell this from your shopping list.
      That's the point of XML, storing information in a way that your computer can easily understand what's going on.
      Chuck an tag at the top, and it can check against the schema to see that it actually makes sense.
      You can run it through an XSLT script, and get HTML, or the plain text form above, or maybe combine it with some other documents, and get a different type of XML document.
      All of this stuff would be a whole lot harder in plain text, because your computer wouldn't know what the document meant, let alone how to do anything interesting with it.
    • You can compress XML with any standard compression technique.

      For example,SVG [w3.org] - an XML standard for Vector Graphics - expects all conformant viewers to be able to handle gzip/gunzip compression.

      They compress down as small as binary Flash (.swf) files.

    • SAML is specified using XML Schema which in turn is specified in terms of the XML Infoset.

      If you want to reduce the size of the XML messages I suggest that you use a more efficient XML encoding rather than a compression algorithm.

      A compression algorithm such as LZW takes entire documents and makes them smaller, this is highly efficient in terms of space but computationally intensive. Decompression typically requires the whole message or at least a substantial part of it to be read before decompression can begin.

      Finaly, the problem is not that "is complex enough that nobody tends to parse it right." ASN.1 is a classical example of a good idea that was butchered in committee. The most half baked example of which being the DER encoding rules which are simply derranged. There is no 'tends' about it, no two full scale ASN.1 tools I have used can be relied on to interoperate. Some fail to interoperate with themselves.

    • Just a thought, but what about a convertor/interpreter which will reduce the tags to the shortest possible tag, e.g. the tag


      converted to

      etc... Just a thought! I guess the space recovered would be limited and it would mean the other end would have to reconstruct it.
  • For the longest time, the Gallagher brothers were total wankers. It's very good to see them opening themselves to good things like open XML standards and frameworks.
  • Oasis has approved the SAML 1.0 specification.

    does this finally mean that XML is more popular than the beatles?

  • Can this kind of thing be turned off? Or will someone using a computer at an Internet café automatically leave their password around for the next user on the machine to use?
  • Well I see that since BMG is stopping the production of CDs [slashdot.org] it looks like one band is taking things into thier own hands!

    Oh wait.. RTFA(s)
  • Just when I thought I was finally able to explain PKI and OpenPGP to my friends and customers, this comes out...

    I hope it's for the best, not just another buzzword.

    After all, I can see OpenPGP encrypted files + dettached signatures encapsulated in XML sooner that this finishes being "approved".

    I assure you, I see it! It's red, and has yellow dots.. ah well... ;)
  • It's going to be interesting to see which one wins. This is going to be like the VHS/Beta battle. One will be the superior technology, the other will be marketed and distributed better. I wonder which will turn out to be which.
  • Should we really be putting bad British pop bands in charge of secure frameworks?

    What's next -- the Supergrass Encryption protocol?
  • The project that I wrote uses SAML to pass authentication information to the various data providers.

    Anyone interested in it can check out the project at http://www.nchelp.org/Meteor.htm [nchelp.org].
    If you're interested in looking at the code it can be downloaded from http://www.meteorcentral.com/ [meteorcentral.com]
    It is licensed via the LGPL.
  • ....the Gallagher brothers knew was SAML was.....infact, I'm surprised they know what a computer is!

    -pysco
  • Those who are actually interested in using this stuff instead of just griping about things they don't understand should take a look at OpenSAML, a Java & C++ library for creating & grokking SAML assertions, at http://www.opensaml.org/

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Thursday November 07, 2002 @01:09AM (#4614583)
    Comment removed based on user account deletion
    • Yes, XML is an annoying buzzword which clueless managers (who learn everything they know from trade rags) think should be used for everything. However this is actually a legit use of the technology. If your goal is to have a generic security language, you might as well use a generic data format.

      I find its actually a good filter - where people quote knowledge of XML in their skill-set with no mention of any specific XML technologies you know they've just dropped in a current buzzword for good measure. Its about as useful as saying "I know about files", its that generic!
    • It can also be encrypted using XML-Encryption or just sent over an SSL connection

      What is XML Encryption, btw? Is it different from
      Encrypting XML? Is the encrypted content XML?
      If yes, are the XML parsers supposed to support them too?

  • Cool! (Score:1)

    by ENOENT ( 25325 )
    I've always wanted my XML application to be given the stamp-of-approval by a sexy redheaded gymnast-assassin robot!

    (For the Sluggy-challenged, check the link in my sig.)
  • I THINK THERE SHOULD BE SOMETHING in science called the "reindeer effect."
    I don't know what it would be, but I think it'd be good to hear someone say,
    "Gentlemen, what we have here is a terrifying example of the reindeer effect."
    -- Jack Handley, The New Mexican, 1988.

    - this post brought to you by the Automated Last Post Generator...

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close