Internet Draft                                          Y. Y. Goland 
   Document: draft-goland-sso-human-00.txt                     Openwave 
   Expires: May 2002                                      November 2001 
                                      
          Zero Install Single Sign On Solution for a HTTP Browser 
                                      
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that     
   other groups may also distribute working documents as Internet-
   Drafts. 
    
     Internet-Drafts are draft documents valid for a maximum of six 
     months and may be updated, replaced, or obsoleted by other 
     documents at any time.  It is inappropriate to use Internet-Drafts 
     as reference material or to cite them other than as "work in 
     progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This document defines how to enable a federated single sign on (SSO) 
   environment across HTTP using existing HTTP/1.0 compliant clients 
   that support 303 redirects. 
    
   The goal of the system is to enable a user to authenticate to 
   multiple websites using a single identity. Further, the mechanism 
   must work without requiring the user to upgrade their existing web 
   client. 
    
 














  
Goland                                                               1 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
Table of Contents 
    
Status of this Memo...................................................1 
Abstract..............................................................1 
1.  Overview.........................................................4 
2.  Conventions used in this document................................4 
3.  Glossary.........................................................5 
4.  Protocol Flow Overview...........................................5 
 4.1.  Requirements.................................................5 
 4.2.  Implementation...............................................6 
 4.3.  Explanation.................................................10 
   4.3.1  Why put the burden on IPs/AAs instead of SPs?............10 
   4.3.2  Why the V shape?.........................................10 
   4.3.3  Isn't this whole system just a man in the middle attack 
   waiting to happen?...............................................11 
   4.3.4  Where are the cookies?...................................12 
   4.3.5  Won't this system fail to work if the client's initial 
   request was a POST?..............................................12 
5.  User IDs........................................................13 
 5.1.  Requirements................................................13 
 5.2.  Implementation..............................................13 
 5.3.  Explanation.................................................13 
   5.3.1  Why a URI for a User ID?.................................13 
   5.3.2  How do User IDs get generated? Who owns a principal's User 
   ID?    13 
6.  Discovering an IP's AA..........................................14 
 6.1.  Requirements................................................14 
 6.2.  Implementation..............................................14 
 6.3.  Explanation.................................................15 
   6.3.1  What's a fixed path?.....................................15 
   6.3.2  Why do IPs have DNS names instead of full URLs?..........15 
   6.3.3  Why all the SHOULDs?.....................................16 
   6.3.4  What about user names? E-mail addresses? Telephone numbers? 
   Etc. Why don't we use them to identify IPs?......................16 
   6.3.5  What about SRV records? Why only U?......................16 
7.  Forming the request for authentication..........................16 
 7.1.  Requirements................................................16 
 7.2.  Implementation..............................................16 
   7.2.1  Examples.................................................17 
 7.3.  Explanation.................................................18 
   7.3.1  How will the SP match responses to their requests? Aren't 
   there standards for this?........................................18 
   7.3.2  Why are the SP and IP elements required?.................19 
   7.3.3  If we have User IDs why do we have to deal with User Names?
          19 
8.  Securing and sending the request for authentication.............19 
 8.1.  Requirements................................................19 
 8.2.  Implementation..............................................19 
 8.3.  Explanation.................................................20 
9.  Decoding and responding to the authentication request...........20 
 9.1.  Requirements................................................20 
 9.2.  Implementation..............................................20 
   9.2.1  Examples.................................................22 
  
Goland                                                               2 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
 9.3.  Explanation.................................................23 
   9.3.1  Why aren't the mappings between user names and user IDs 
   required to be clearly identified in the response?...............23 
   9.3.2  Is the logoff URL enough? Don't we need to specify names and 
   such to make usable UI?..........................................24 
10.  Use Case Scenarios.............................................24 
 10.1.   First Visit................................................24 
 10.2.   Second Visit...............................................27 
 10.3.   A new SP...................................................27 
 10.4.   Third Visit................................................27 
11.  XML Schema.....................................................28 
12.  Security Considerations........................................29 
13.  IANA Considerations............................................29 
14.  References.....................................................29 
15.  Author's Address...............................................29 






































  
Goland                                                               3 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
      
1. Overview 
      
   This specification is the first entry in what is expected to be a 
   four part series: 
    
     draft-goland-sso-human-00.txt 
     draft-goland-sso-proc-00.txt 
     draft-goland-sso-oldwap-00.txt 
     draft-goland-sso-moveip-00.txt 
    
   The first draft focuses on creating a SSO system where the client is 
   a human using a HTTP compliant browser. The specification only 
   requires that the browser support 303 redirects and can handle URLs 
   of around 4 KB in length. No assumptions are made about the media 
   handling capabilities of the browser. 
    
   The second draft focuses on creating a SSO system where the client 
   is a program that is able to act without the direct intervention of 
   humans. For example, a device that needs to log itself on in order 
   to report status or a proxy acting on behalf of a client.  
    
   The third draft focuses on creating a SSO system where the client is 
   one of the first generation WAP clients. These clients have 
   limitations that PC based clients and subsequent WAP clients do not 
   have. Rather than requiring everyone to adopt the more complex 
   message flow this requires, it was felt prudent to separately 
   specify how to deal with these clients. 
    
   The fourth draft provides protocols to enable one IP to move 
   identity information to another IP. This protocol is used when a 
   principal either wants to switch IPs or wishes to enable multiple 
   IPs to authenticate the same identity. This draft will also specify 
   how clients can create accounts with IPs, including providing their 
   user ID. 
    
   A note on the structure of the drafts: Each section of each draft is 
   separated into three parts. 
    
        Requirements - What do we need to do? 
        Implementation - How do we do it? 
        Explanation - Why did we do it that way? 
    
   Once the draft is sufficiently mature the requirements sections will 
   be cut out and put into their own draft. The implementation sections 
   will remain as the actual 'standard'. The explanation sections are 
   usually gathered together and published somewhere on-line so 
   developers and those working to extend the standard can understand 
   the decisions that led to the standard's design. 
    
2. Conventions used in this document 
    

  
Goland                                                               4 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [1]. 
    
3. Glossary 
    
   Identity -  
   [Ed. Note: Identity seems a little like pornography, I can't define 
   it but I know it when I see it.] 
    
   Principal - The principal is the entity that wishes to be 
   authenticated. There are two types of principals, human and 
   programmatic. This specification only deals with human principals. 
    
   Client - The client is the web browser used by the principal. 
    
   Service Provider (SP) - The service provider is a network entity 
   that provides services to principals. 
    
   Identity Provider (IP) - A service provider whose creates 
   identities. 
    
   Authentication Authority (AA) - A service provider that 
   authenticates identities on behalf of IPs. 
    
   The separation of the IP and the AA is made mostly to enable this 
   specification to conform to the common usage of the term AA as given 
   in sources like SAML. 
    
4. Protocol Flow Overview 
    
4.1.    Requirements 
    
   The system MUST function on existing HTTP web browsers that support 
   303 redirects. 
    
   The system MUST assume the existence of multiple independent and 
   unrelated IPs. 
    
   The system MUST assume that SPs may only be willing to accept 
   identities from a subset of all available IPs. 
    
   The system MUST assume that IPs may only be willing to allow their 
   identities to be used by a subset of all available SPs. 
    
   The system MUST assume that principals will have multiple 
   identities. The system MUST assume that a principal may have 
   multiple identities with a single IP. The system MUST assume that a 
   principal may have multiple identities with multiple IPs. The system 
   MUST assume that the principal may have a single identity that the 
   AAs for multiple IPs can authenticate. 
    

  
Goland                                                               5 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   The system MUST NOT make any assumptions regarding relationships 
   between IPs, AAs and SPs, for example, a SP could also be it's own 
   IP and AA. 
    
   The system MUST assume that authentication can only occur through 
   the services of an AA. The system MUST assume that multiple IPs may 
   use the services of the same AA. The system MUST assume that a 
   single IP may use the services of multiple AAs. The system MUST 
   assume that AAs act on behalf of IPs and so all authentication 
   information is associated with IPs not AAs. The system MUST assume 
   that the AAs can respond to any authentication challenges on behalf 
   of the IP. 
    
   The system MUST NOT require clients to have any capabilities beyond 
   HTTP compliance and support for 303 redirects. Clients MUST NOT be 
   required to install any additional software in order to implement 
   this system. Note that SP and IPs MAY choose to include additional 
   requirements such as support for HTTP Cookies, the ability to 
   display HTML, WML, etc. 
    
   The system SHOULD be made as easy as possible for SPs to implement, 
   even if this means putting additional complexity on IP/AAs. 
    
4.2.    Implementation 
    
   Today when a user (herein called a principal) uses their web browser 
   (herein called a client) to go to a website (herein called a service 
   provider) to buy something or perform any other action which 
   requires some level of security the principal is required to 
   authenticate themselves. 
    
   The typical experience is that the service provider will send a HTML 
   form over TLS or use basic or digest authentication to get a name 
   and password from the principal. Every service provider the 
   principal visits has it's own authentication database and requires a 
   different name and password from the principal. 
    
   Requiring principals to maintain stacks of names and passwords is 
   not good from either a security perspective (the principal tends to 
   write the names and passwords down) or from a user experience 
   perspective. 
    
   What is desired is the ability for a principal to authenticate 
   himself or herself once and then be able to travel to any service 
   provider and have that service provider recognize the principal's 
   authentication. 
    
   Providing this experience requires the introduction of two 
   additional entities besides the principal, client and service 
   provider. They are the identity provider and the authentication 
   authority. 
    

  
Goland                                                               6 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Identity providers are in the business of providing identities. At 
   their simplest an identity provider just maintains a database of 
   user names, user IDs and passwords. 
    
   The authentication authority is the actual service, usually but not 
   necessarily, owned by the identity provider. This is the actual web 
   server that handles authenticating the user. The authentication 
   authority is the one who sends out the HTML Form over TLS or makes 
   the basic or digest challenge to authenticate the user. 
    
   The user experience in this system is that first a principal goes to 
   an identity provider to get an identity. The identity provider will 
   create three values - a user name, a user ID and a password. The 
   user name is a human friendly name that's easy to type in and 
   remember. For example, principal@ip.example.com. The user ID is a 
   URI that is globally unique, for example, a UUID URI. The user ID is 
   the principal's "real" name. That is, user names always map to user 
   IDs. Whenever a service provider wants to track a principal they are 
   required to use the user ID not the user name to do it. Both user 
   IDs and user names are provided because user IDs tend to be long 
   ugly complex expressions that no human could ever remember. 
    
   The reason for using the user ID is to enable portability. Imagine 
   that the principal doesn't like their identity provider and wants to 
   move to another one. This is a similar experience to changing credit 
   card providers. You can't take your credit card number with you so 
   changing providers means getting a new number. This in turn means 
   contacting everyone who you have given the old number to and getting 
   them to change to the new number. This is an awful experience. To 
   prevent it we use User IDs. That way if a principal wants to change 
   their identity provider they take their User ID with them. 
    
   Once the principal has a user ID with an identity provider the 
   principal can begin to use that ID. When the principal navigates 
   their client to a service provider the service provider has no way 
   of knowing which identity provider the principal is using. Without 
   that information the service provider has no idea how to actually 
   authenticate the principal. Therefore the principal must tell the 
   service provider who the principal's identity provider is. This 
   requires the identity provider have an easily memorable name that a 
   service provider can translate into a network address. This system 
   already exists and is called DNS. Therefore identity providers are 
   required to have DNS names. 
    
   Having principals typing in DNS names is not the world's greatest 
   user experience, it is only intended as a minimum guarantee of 
   interoperability. There are other avenues available to service 
   providers to find out the principal's identity provider that are 
   more user friendly. For example, if the service provider only 
   accepts identities from a relatively small group of identity 
   providers (this is like taking American Express but not Visa) then 
   the service provider can just list the identity providers it accepts 
   and let the principal click on the right one. Alternatively the 
  
Goland                                                               7 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   service provider can accept a user name from the principal that the 
   service provider knows how to translate into a network address. For 
   example, if the principal's user name is an e-mail address then the 
   service provider can pull out the DNS name from the e-mail. If the 
   principal's user name is a phone number then the service provider 
   can use ENUM to translate it into a network address, etc. 
    
   Once the service provider knows which identity provider the 
   principal is using the service provider still needs to know which 
   authentication authority the identity provider is using. See below 
   for more details on how NAPTR DNS records are used to solve that 
   problem. 
    
   The actual authentication experience uses the following message 
   pattern. Please refer to section 10 for more detailed message flow 
   examples. 
    
    
     Client               SP    AA 
       |                  |     | 
       |1.HTTP GET Request|     | 
       ------------------->     | 
       |2.HTML Form asking for IP's Name 
       <-------------------     | 
       |3.HTML Form response with IP's Name 
       ------------------->     | 
       |4.303 to AA for Auth    | 
       <-------------------     | 
       |5.HTTP GET        |     | 
       -------------------------> 
       |6.HTML Form or basic/digest to get Auth Info 
       <------------------------- 
       |7.HTML Form or basic/digest response 
       -------------------------> 
       |8.303 to SP       |     | 
       <------------------------- 
       |9.HTTP GET        |     | 
       ------------------->     | 
       |10.Return Page    |     | 
       <-------------------     | 
    
   The actual communication pattern looks like a V: 
    
       AA                     SP 
        \                    / 
         \                  / 
          \                / 
   5,6,7,8 \              / 1,2,3,4,9,10 
            \            / 
             \          / 
              \        / 
               \      / 
                Client 
  
Goland                                                               8 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
    
   The AA and SP never directly communicate. All communication is 
   through the client. Because the SP and AA do not directly 
   communicate the only way to pass information between them is to 
   encode information into the URL that the client is redirected to. 
   This means that clients and their associated infrastructure (e.g. 
   proxies, firewalls, etc.) need to handle URLs of a fairly large 
   size. Experience indicates that 4 Kilobytes is the maximum URL size 
   that is widely supported on the Internet. 
    
   Steps 1 & 2 - The client asks for a page (GET/POST) that the 
   principal has not been authenticated to access. The SP responds with 
   a HTML form or similar UI asking for the principal's IP's DNS name. 
   Depending on the actual UI the SP may ask the principal to choose an 
   IP from a list, type in the IP's DNS name or provide a user name 
   that is DNS resolvable, such as a telephone number or e-mail 
   address. Using a DNS NAPTR record lookup the SP can translate the 
   IP's DNS name into a HTTP URL pointing at the IP's AA(s). See 
   section 6 for more details on the use of NAPTR. 
    
   Steps 3 & 4 - The SP will create a SOAP request asking the AA to 
   authenticate the principal. The SP will encrypt the request, URL 
   encode it and glue it on the end of the AA's URL after the "?" 
   character. The SP will then redirect the client to that address. 
   Please see section 8 for details on how requests are encrypted, 
   signed, etc. 
    
   Steps 5 & 6 - The AA will pull the end off the URL, decode it and 
   decrypt it. Assuming the request is authenticated the AA will ask 
   the principal, using HTML forms, basic/digest, etc. to provide 
   authentication information. 
    
   Steps 7 & 8 - In it's request the SP included the URL that the AA 
   should redirect the client to in order to deliver the AA's response. 
   Assuming the principal successfully authenticates the AA will create 
   a SOAP response indicating that the principal was successfully 
   authenticated. The response will be encrypted and URL encoded and 
   glued to the end of the URL the SP supplied in it's request after a 
   "?". The AA will then redirect the client to that URL. The AA is 
   also likely to put a cookie on the client establishing an 
   authentication session between the client, principal and AA. 
    
   Steps 9 & 10 - The SP will pull the end off the URL, decode it and 
   decrypt it. Seeing that the principal/client has been authenticated 
   the SP will return the requested page. The SP is also likely to 
   stick a cookie on the client beginning the SP authentication 
   session. 
    
   In reading through this specification certain communities will 
   become worried that they don't see references to their particular 
   needs. For example, this specification refers to the use of HTML 
   forms but not to WML forms or this specification refers to 
   basic/digest but not to various biometric or smart card HTTP 
  
Goland                                                               9 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   extensions. HTTP's negotiation mechanisms enable HTTP clients and 
   servers to determine, at run time, what capabilities the other has 
   and respond accordingly. Therefore all these extensions can be 
   safely used with this specification. 
    
4.3.    Explanation 
    
4.3.1   Why put the burden on IPs/AAs instead of SPs? 
    
   The burden is placed on the IPs and AAs because they are expected to 
   be run by professional organizations dedicated to the management and 
   security of user information. SPs, on the other hand, are business, 
   home user's systems, etc. that just want to leverage authentication. 
   As such it is expected that the IPs and AAs are in a significantly 
   better position to handle increased complexity related to the 
   functionality of this system than the average SP is. 
    
4.3.2   Why the V shape? 
    
   Two communication patterns seemed to meet the needs of the zero 
   install solution. The first was the V pattern described above with 
   the SP and AA on the top and the client on the bottom. Another 
   pattern is the triangle. The message flow in a triangle pattern 
   would look like: 
    
     Client               SP    AA 
       |                  |     | 
       |1.HTTP Request    |     | 
       ------------------->     | 
       |2.Request for IP's Name | 
       <-------------------     | 
       |3.Supply IP's Name|     | 
       ------------------->     | 
       |4.303 to AA URL + Short ID + SP's Address (< 128 bytes) 
       <-------------------     | 
       |5.HTTP GET        |     | 
       -------------------------> 
       |6.Request Auth Info     | 
       <------------------------- 
       |7.Provide Auth Info     | 
       -------------------------> 
       |                  |8.Confirm to SP that principal is OK 
       |                  <------ 
       |                  |9.Send required HTTP response 
       |                  ------> 
       |10.303 to SP      |     | 
       <------------------------- 
       |11.HTTP GET       |     | 
       ------------------->     | 
       |12.Return Page    |     | 
       <-------------------     | 
    

  
Goland                                                              10 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   The previous forms a triangle pattern because every member of the 
   system communicated with every other member.  
    
   Advantages to the triangle pattern: 
    
   1) Rather than trying to shove XML into URLs we can use real XML 
   inside of nice roomy HTTP request/response bodies. 
    
   2) Because the SP and AA communicate directly they can use 
   authentication/encryption technologies that are not available when 
   you use URLs as your 'transport'. For example, TLS and IPSEC. 
    
   3) We enable clients and/or infrastructures that cannot handle large 
   URLs to participate in the authentication system. The URLs used in 
   this system only need to contain short session IDs that help the SP 
   and AA make sure they are talking about the same client/principal. 
    
   Disadvantages of the triangle pattern: 
    
   1) The system isn't very stable. Somewhere between step 7 and 12 the 
   AA must tell the SP that the principal/client is authenticated. This 
   means that at some point the client will have an outstanding request 
   that cannot be answered by the SP until it gets confirmation from 
   the AA. Given the vagaries of Internet connectivity this can result 
   in some pretty nasty user experiences. It's especially bad because a 
   badly implemented AA can make a well-implemented SP look bad. 
    
   2) It's slower. Rather than 5 network round trips this system 
   requires 6. That extra round trip, averaged over the millions of 
   logons (we hope) a day makes a big difference. 
    
   In the end there isn't a slam-dunk reason to choose one over the 
   other. Upon weighing all the possible factors the V pattern seems 
   simpler to implement for all involved and it requires less round 
   trips. So over all, simpler and faster would seem better. 
    
4.3.3   Isn't this whole system just a man in the middle attack waiting 
     to happen? 
    
   Yes. 
    
   For a system like this to be secure against man in the middle 
   attacks every player has to fully authenticate themselves to every 
   other player. The problem with this system is that the client never 
   directly authenticates itself to the SP. Even if both legs of the V 
   are run over TLS there is still no good way to get around a man in 
   the middle attack. 
    
   In the end security is like insurance. The amount of insurance you 
   buy is supposed to offset the amount of risk you are unwilling to 
   take upon yourself. Security works the same way. For some 
   applications the cost of new clients (insurance) outweighs the risk. 
   So those applications can reasonably make use of this system. 
  
Goland                                                              11 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
    
   Those for whom the risk is too great should look at draft-goland-
   sso-proc-00.txt that doesn't suffer from the man in the middle 
   attacks. 
    
4.3.4   Where are the cookies? 
    
   While HTTP cookies are referred to in this specification they are 
   never part of the standardized authentication mechanism. What 
   cookies, if any, to use on a client is an issue between the SP and 
   the client and the IP and the client. From an interoperability 
   standpoint there is no need to specify anything about the usage of 
   cookies. In fact, it is possible to implement the system without 
   cookies. One can use TLS and/or one can encode the information that 
   would have gone into cookies into URLs instead. Either way, the 
   actual state management mechanism between the client and SP/IP isn't 
   something this specification needs to address in order to achieve 
   interoperability. 
    
4.3.5   Won't this system fail to work if the client's initial request 
     was a POST? 
    
   Trying to do authentication off POSTs is usually a less than great 
   idea. That's why most sites put in a GET page to trigger 
   authentication before a POST page. But if a site absolutely has to 
   do authentication off a POST then there are a couple of ways to do 
   it. 
    
   1. Take the POST data submitted in step 1 and hide it as invisible 
   fields in the HTTP Form returned in step 2. 
    
   2. In step 3 the invisible fields with the POST data will be 
   returned with the principal's response to the request for their IP. 
   Take the POST data and put it into the context field in the SOAP 
   request that gets sent back in step 4. 
    
   3. In step 9 the client will return with the SOAP response that will 
   contain the context element that will contain the POST field data. 
   The response in step 10 can then be the response that would have 
   been returned had the client already been authenticated back in step 
   1. 
    
   A variation on the previous strategy, especially if there is a lot 
   of POST data and one is going to make the redirect URL too large, is 
   to record the POST data in a local DB and just send around a pointer 
   to that DB location in the context. 
    
   An alternative strategy is to return the form page in step 10 that 
   the user originally saw in step 1 and make them enter all the data 
   again. 
    
    

  
Goland                                                              12 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
5. User IDs 
    
5.1.    Requirements 
    
   User IDs MUST be portable between IPs and usable across multiple 
   IPs. 
    
   User IDS MUST be unique across all principals for all time. 
    
5.2.    Implementation 
    
   The term User ID is used for historical reasons even though the term 
   Principal ID would be more accurate. 
    
   A User ID is defined by this specification as a URI [2]. The URI 
   that is used MUST be globally unique and assignable to one and only 
   one principal. Note that a principal could actually be a group 
   principal, but that is a subject beyond the scope of this paper. 
   There is no requirement that the User ID URI be resolvable. 
    
5.3.    Explanation 
    
5.3.1   Why a URI for a User ID? 
    
   For user IDs to be transportable between IPs (or usable across IPs) 
   the IDs must be globally unique. We could have just grabbed a single 
   namespace, such as UUIDs and declared that to be the namespace from 
   which user IDs must be taken. But there didn't seem to be any 
   inherent interoperability boost by so doing. Rather, using the URI 
   namespace, which is robustly extensible by multiple sources, seems a 
   better solution. So long as a particular URI scheme meets the 
   uniqueness requirements then it can be used. 
    
5.3.2   How do User IDs get generated? Who owns a principal's User ID? 
    
   User Names, the friendly names like jo@ip.example.com or even simple 
   strings like "Jo" are owned by the identity provider. If a principal 
   changes their IP then they loose their user name. 
    
   This is why user IDs are so important and why SPs are required to 
   track principals using user IDs and not user names. When a user 
   moves IP they can (hopefully) take their user ID with them and that 
   way when they go back to a SP they have visited before and 
   authenticate with the new IP the SP will see that the user ID is 
   identical to the one they have seen before and realize its the same 
   principal. 
    
   User IDs are likely to come from lots of different places and have 
   lots of different policies attached. Trying to presuppose usage 
   didn't seem very productive. For example, a company can be 
   reasonably expected to own all the user IDs that it's employees use 
   in the conduct of business on behalf of the company. On the other 
   hand, consumers will probably want to own their own IDs. In the end 
  
Goland                                                              13 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   the generation and ownership of IDs is a matter between principals 
   and their IP. I suspect this will turn out like the DNS registration 
   situation. Some DNS registrars claim that all DNS names they 
   register really belong to them and that they simply 'lease' the 
   names to the people who register. Other DNS registrars say that the 
   name belongs to the people who register and they simply provide 
   resolution services. In the end people are free to choose either 
   type of company. 
    
6. Discovering an IP's AA 
    
6.1.    Requirements 
    
   IPs MUST be identifiable by principals using easily memorized names. 
    
   An IP's AA MUST be discoverable in a manner controlled by the IP and 
   without requiring the use of fixed paths. 
    
6.2.    Implementation 
    
   To authenticate a principal the SP has to know which IP the 
   principal is using. Once the principal is know then the SP has to 
   find out which AA the principal wants the SP to use. 
    
   Principals are expected to be able to either directly or indirectly 
   name their IPs. The Internet already provides a standard solution 
   for naming, DNS. As such, SPs SHOULD allow principals to identify 
   their IP using DNS resolvable names. A SP is free to use other 
   means, such as a list of known IPs. 
    
   A SP SHOULD enable a principal to identify their IP using a straight 
   DNS name. For example, if a principal's IP has the DNS name 
   ip.example.com then the SP should let the user just type in that DNS 
   address. SPs SHOULD accept HTTP URLs as well as straight DNS names 
   and be able to remove the DNS portion of the name. For example, if 
   the principal typed in http://ip.example.com/ the SP is encouraged 
   to handle this gracefully. The SP should also be aware of the 
   potential inappropriate use of the www prefix on an IP name and be 
   ready to remove it. So, if the user typed in 
   http://www.ip.example.com then the IP should try both ip.example.com 
   and www.ip.example.com in the DNS resolution process defined below.  
    
   The SP MAY accept other DNS resolvable names such as e-mail address 
   or phone numbers. But in general the use of these names is 
   discouraged as they force the principal to identify himself or 
   herself to the SP. 
    
   How the SP gets the IP's DNS name from the principal is a matter to 
   be negotiated directly between the SP and the principal's client. It 
   is expected that standard mechanisms such as HTML forms will be 
   used. 
    

  
Goland                                                              14 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Once the SP has the IP's DNS name the SP needs to determine which AA 
   the IP wishes to use. This requires performing a lookup into a 
   database into which the IP's DNS address is the key and the output 
   is the HTTP URL of the AA to redirect the user to. 
    
   Such a lookup mechanism already exists in the form of the DNS NAPTR 
   [3] record type. The IP's DNS name is to be used as the initial 
   domain lookup value in DNS. For our purposes the string to be 
   compared against is also the IP's DNS name. The goal of the NAPTR 
   lookup is to find a NAPTR record advertising the HTTP protocol with 
   the ZISSO resolution service. The end value calculated from the 
   terminal HTTP+ZISSO NAPTR record MUST return a HTTP/HTTPS URL that 
   points to the AA to be used in the next step of the authentication 
   process. 
    
   [Ed. Note: Need to check if it's o.k. to return a HTTPS URL when the 
   protocol type of the NAPTR record is HTTP.] 
    
6.3.    Explanation 
    
6.3.1   What's a fixed path? 
    
   The phrase fixed path refers to the strongly discouraged practice of 
   enable resource discovery by reserving a path in the HTTP URL path. 
   For example, robots.txt files are always found at 
   http://somedomain.com/robots.txt. Reserving paths like this are nice 
   because once you know the domain name you can directly go to the 
   appropriate location. So, for example, if you know the IP's name is 
   ip.example.com then you can go to http://ip.example.com/zisso/aa or 
   some equally magical path and get to the AA. 
    
   In practice this type of solution proves problematic. It just seems 
   to always break or prove too limited. Companies will have policies 
   that say things like "You can only control paths inside of your 
   division". So if the guys running the AA are at 
   http://ip.example.com/aadivision then their AA path has to have that 
   URL as it's parent. It also makes load balancing a complete 
   nightmare as everyone runs to exactly the same URL. 
    
6.3.2   Why do IPs have DNS names instead of full URLs? 
    
   In the previous section we only required that users specify an IP's 
   DNS name rather than providing a full path. This is unfortunate 
   because it means that anyone who wants to be an IP has to own their 
   own domain name. This isn't a giant hurdle but why put up any 
   hurdles if you don't have to? 
    
   In this case the decision was made to require IPs to be identified 
   by their DNS name in order to simplify matters for principals. We 
   needed a way to identify IPs that would be easy to remember and that 
   means it needed to be short. DNS names were the shortest open 
   standard naming mechanism available. 
    
  
Goland                                                              15 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
6.3.3   Why all the SHOULDs? 
    
   The reason to use a SHOULD when there are good reasons to break a 
   rule. For example, we specify that SPs SHOULD accept DNS names as IP 
   names. But if the SP is in a walled garden with IPs that always use 
   phone numbers, for example, then the SP has a good reason to break 
   the rule. 
    
6.3.4   What about user names? E-mail addresses? Telephone numbers? 
     Etc. Why don't we use them to identify IPs? 
    
   An SP can use any value it wants to identify an IP. Our goal here is 
   to just provide the minimum needed for interoperability. So, for 
   example, if a SP uses a group of IPs that share a single user name 
   database then the SP can just ask the user to give their user name 
   and do a lookup in the database. 
    
   Telephone numbers also work well to identify IPs. One would take the 
   phone number, apply ENUM but look for the HTTP+ZISSO service. 
    
   E-mail addresses are easy, just pull out the DNS name. 
    
   Etc. 
    
6.3.5   What about SRV records? Why only U? 
    
   SRV records do not allow for the user of paths, which means that all 
   HTTP URLs derived from the SRV record would have to be of the form 
   http://dnsname/. There is no place to put a URI path in a SRV 
   record. This seems to restrictive so rather than go and explain how 
   to use S records it just seemed simpler to ban them. 
    
7. Forming the request for authentication 
    
7.1.    Requirements 
    
   The authentication request MUST NOT invent YARPCF (Yet Another RPC 
   Format). 
    
   The authentication request MUST NOT require that the SP know any 
   information about the principal. 
    
   The authentication request MUST allow the SP to specify where the 
   client is to be redirected in order to deliver the AA's response. 
    
7.2.    Implementation 
    
   Now that the SP knows the AA's address it is possible to create a 
   request for the AA to authenticate the principal. The request is 
   expressed using a SOAP body inside of a SOAP [4] envelope. 
    
   XML Element Name: Lookup 

  
Goland                                                              16 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Children: sp, ip, username (0, unbounded), userid (1, unbounded), 
   return (1,unbounded), context (0) 
   Explanation: The Lookup element specifies that this is a request 
   from a SP to an AA asking that the specified principal be 
   authenticated. 
    
   XML Element Name: sp 
   Explanation: The sp element provides the DNS name for the SP making 
   the request. 
    
   [Ed. Note: We should probably allow multiple SP names to be listed. 
   Although this would probably mean making the return XML element a 
   child of SP.] 
    
   XML Element Name: ip 
   Explanation: The ip element provides the DNS name for the IP making 
   the request. 
    
   [Ed. Note: There really isn't a good reason not to allow SPs and IPs 
   to be referred to by URLs in these elements. We just need a standard 
   way of referring to a DNS name (how about a DNS url?). Need to 
   update the syntax to allow this.] 
    
   XML Element Name: username and userid 
   Explanation: The SP can include a list of usernames and user ids in 
   the request. If included then the authentication request can only 
   succeed if the principal can be authenticated by the AA as being one 
   of the usernames and/or userids. There is no way to request that the 
   AA authenticate the principal as being more than one of the 
   usernames/user IDs.  
    
   XML Element Name: return 
   Explanation: The return XML element specifies what URL the client is 
   to be redirected to in order to return the AA's response to the 
   Lookup request. If multiple return XML elements are provided then 
   the AA may choose to use any of them. The AA MAY assume that the 
   elements are listed in priority order. 
    
   XML Element Name: context 
   Explanation: The context XML element is used to record data that the 
   SP will use to re-establish context upon receiving the AA's 
   response. The AA MUST return the contents of the context element 
   unchanged in the response to the request. 
    
7.2.1   Examples 
    
   Below is an example of a request to authenticate a principal: 
    
   <env:Envelope  
    xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'> 
     <env:Body> 
       <z:Lookup xmlns:z='zisso:1'> 
         <z:sp>shoestore.com</z:sp> 
  
Goland                                                              17 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
         <z:ip>myip.com</z:ip> 
         <z:username>principal</z:username> 
         <z:userid>UUID:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</z:userid> 
         <z:return>http://www.shoestore.com/zisso</z:return> 
         <z:return>foo:bar/blah/ick</z:return> 
         <z:context>This is some context information</z:context> 
       </z:Lookup> 
     </env:Body> 
   </env:Envelope> 
    
   In this request the SP, identified as shoestore.com, asks the AA to 
   authenticate the principal as either being the principal known by 
   the username "principal" and/or as being the principal known by the 
   listed user ID. Shoestore asks that when authentication is complete 
   the AA redirect the principal's client to 
   http://www.shoestore.com/zisso. The SP also asks the content of the 
   context element be returned, verbatim, in the AA's response. 
    
   The previous example is a maximal example using all the elements 
   that are defined below for use in a request. An example using the 
   fewest elements possible would look like: 
    
   <env:Envelope  
    xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'> 
     <env:Body> 
       <z:Lookup xmlns:z='zisso:1'> 
         <z:sp>shoestore.com</z:sp> 
         <z:ip>myip.com</z:ip> 
         <z:return>http://www.shoestore.com/zisso</z:return> 
       </z:Lookup> 
     </env:Body> 
   </env:Envelope> 
    
   In this example the SP doesn't know any of the principal's user 
   names or user IDs so the username and userid elements aren't 
   included. The SP has also chosen to glue context information onto 
   the end of their return URL so a context element isn't included 
   either. 
    
7.3.    Explanation 
    
7.3.1   How will the SP match responses to their requests? Aren't there 
     standards for this? 
    
   The obvious answer is through either the context element or the 
   return URL that can have context data buried in it. But in general 
   it is true that a number of groups have and/or are standardizing 
   mechanisms to associate SOAP requests and responses in asynchronous 
   environments such as ours. The ones I have seen bring in a lot of 
   extra baggage that didn't seem appropriate for us because they are 
   really targeted at business process workflow systems. 
    

  
Goland                                                              18 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
7.3.2   Why are the SP and IP elements required? 
    
   In many environments, especially ones using digital signatures, 
   providing SP and IP values in the content is redundant at best. But 
   in other environments, such as one in which TLS is used on both legs 
   of the V explicitly specifying the SP and IP elements are critical. 
   Rather than trying to confuse things by providing complex rules for 
   when to include the elements and when not to it seemed easier to 
   just always require them. 
    
7.3.3   If we have User IDs why do we have to deal with User Names? 
    
   It isn't very difficult to imagine a SP having a principal's user 
   name and wanting to authenticate them based on that name. 
    
8. Securing and sending the request for authentication 
    
8.1.    Requirements 
    
   It MUST be possible for the authentication request to be encrypted, 
   signed, etc. 
    
8.2.    Implementation 
    
   In order to secure the authentication request for transport the SP 
   and AA need to agree on what security mechanisms to use. 
    
   A SP and AA are always free to negotiate a mutually acceptable 
   authentication mechanism out of band. For example, the SP and AA may 
   already have agreed on a secret key or a set of public keys each 
   would use to encrypt requests and responses.  
    
   [Ed. Note: Not being a security guru I shall not even attempt to 
   specify this section. The key issue is how to enable a SP and AA to 
   dynamically negotiate what type of security to use for the request. 
   This requires agreeing on things like public key versus secret key, 
   checking credentials and agreeing on the actual format to use to 
   encrypt the key. I think, at a minimum, we should provide some sort 
   of standard format that can be used to carry secret key encrypted 
   contents. We could perhaps beat XMLDSIG into serving this role 
   although it's probably too fat to fit onto a URL. We could always go 
   minimalist and having a format like 
   http://ip.example.com/auth?zisso:sid='sp.example.com';<INSERT 
   ENCRYPTED REQUEST HERE>.] 
    
   Once the authentication request has been formed and secured it MUST 
   be URL Encoded as specified in section 2 of [2]. The AA's URL MUST 
   then have the "?" character appended to the end of it and the URL 
   Encoded request appended after that. The SP MUST then respond to the 
   client's request with a 303 HTTP response code and include the 
   previously created URL in the location header. 
    

  
Goland                                                              19 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
8.3.    Explanation 
 
9. Decoding and responding to the authentication request 
    
9.1.    Requirements 
    
   The AA's response to the authentication request MUST include a user 
   ID and be able to provide information regarding when the AA's 
   authentication session with the principal/client is expected to end. 
    
9.2.    Implementation 
    
   The AA will receive authentication requests at the URL the IP listed 
   in the NAPTR lookup. The requests will be secured using the 
   previously discussed means. The AA will need to remove the 
   authentication request from the end of the Request-URI sent by the 
   client, URL decode it and then remove and verify the security. For 
   example, if the authentication request is signed then AA would need 
   to verify the correctness of the signature. 
    
   Assuming the authentication request is authenticate and appropriate 
   then the AA will respond to the client's request with a form or 
   similar mechanism to retrieve the client's credentials. The actual 
   mechanism used is negotiated between the client and the AA and is 
   out of scope for this specification. 
    
   The AA places the response to a SP request inside of a 
   LookupResponse XML element inside of a SOAP body inside of a SOAP 
   envelope. 
    
   XML Element Name: LookupResponse 
   Children: context (0), (Success | SPSecurityFailure | RequestRefused 
   | SyntaxError | NoMatches | PrincipalAuthFailed) 
    
   XML Element Name: context 
   Explanation: If a context XML element was included in the request 
   then the AA MUST return it, unchanged, in the response. 
    
   XML Element Name: SPSecurityFailure 
   Explanation: The security that the SP used to wrap the request 
   failed. It is expected that this element is unlikely to ever be used 
   outside of a test environment. After all, responding to a security 
   failure can, in itself, cause a denial of service attack. In 
   addition, depending on the actual security used on the request, the 
   AA may have no idea where to redirect the client to in order to 
   deliver the failure notice. 
    
   XML Element Name: RequestRefused 
   Explanation: The AA refuses to work with the SP for non-technical 
   reasons. For example, the SP may not have an appropriate legal 
   agreement with the IP the AA is representing. 
    
   XML Element Name: SyntaxError 
  
Goland                                                              20 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Explanation: The SP's request did not properly follow the schema. 
   [Ed. Note: Probably should use the SOAP fault codes for this one.] 
    
   XML Element Name: PrincipalAuthFailed 
   Explanation: The AA was not able to authenticate the principal or 
   was unable to authenticate the principal as any of the user names or 
   ids listed in the request (if there were any). 
    
   XML Element Name: Success 
   Children: sp, ip, username (0, unbounded), userid (1, unbounded), 
   aasessionlength, logoff (0,unbounded), 
   Explanation: The AA was able to authenticate the principal. 
    
   XML Element Names: sp & ip 
   Explanation: Same as given in the section of the SP's requests. 
    
   XML Element Name: username 
   Explanation: There is no requirement that the AA provide the SP with 
   a username for the principal. However, if, for whatever reason, the 
   AA wishes to provide such a name then the AA may list as many names 
   as desired. If multiple user names are listed then this means that 
   the principal has been authenticated as being associated with all 
   those user names. 
    
   XML Element Name: userid 
   Explanation: AAs MUST provide a userid for an authenticate user and 
   SPs MUST use the userid when tracking the user. 
    
   XML Element Name: aasessionlength 
   Explanation: Specifies the time and date when the principal's 
   session with the AA will expire. This is meant as a hint to the SP 
   regarding how long it should keep it's own session with the 
   principal before requiring a re-authentication. SPs are free to 
   continue their session with the principal beyond the AA session 
   expiration. For example, if all the communication between the SP and 
   the client has been over a properly authenticated connection (say 
   TLS) then it is reasonable for the SP to continue it's session with 
   the principal even if the AA's session has expired. 
    
   XML Element Name: logoff 
   Explanation: When a user logs out of their SP session it is 
   considered polite if the SP also offers the user the opportunity to 
   logoff from their AA session. To enable this behavior the logoff 
   element provides a URL that the client can go to in order to logoff. 
   The SP can then use that URL in it's own UI. The mere provision of 
   the URL provides no special power as it is expected that performing 
   a HTTP GET on the URL will result in a form explicitly asking the 
   user if they wish to logoff. By providing the logoff URL to the SP 
   the AA makes it easier for the SP to provide UI that leads to the 
   AA's logoff screen. The AA can return multiple logoff values and 
   they are to be treated as being in priority order. 
    

  
Goland                                                              21 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   If an authentication request includes multiple usernames and/or ids 
   then the AA must have been able to authenticate the principal as 
   matching at least one of these usernames or ids for a success to be 
   returned. It is possible that a principal may actually have been 
   successfully authenticated as matching several of the listed names 
   or ids. The AA is under no obligation to reveal this to the SP. The 
   only obligation the AA has is: 
    
       1) If the principal matched against a user name and nothing else 
   in the original request then the AA MUST return, at a minimum, the 
   principal name that was matched against in the response along with a 
   user ID. 
    
       2) If the principal matched against a user ID and nothing else 
   in the original request then the AA MUST return, at a minimum, the 
   user ID that was matched against. 
    
       3) If the principal matched against multiple user names and IDs 
   then the AA MUST return at least one value from the list of matched 
   names and IDs. 
    
   Note that none of these requirements in any way hinders the AA from 
   returning additional usernames and user IDs in the response in order 
   to make the SP aware of multiple identities the principal is 
   associated with. 
    
   Also note that SPs cannot assume anything about the relationship 
   between user names and user IDs listed in a response. That is, 
   imagine a principal has the user name UNA that matches to the user 
   IDs UIA and UIB. The principal also has the user names UNB and UNC 
   that match to the user IDs UIC. If the AA returns UNA, UNB, UNC, 
   UIA, UIB and UIC in the response then the SP has no idea how to 
   match the user names to the user IDs. The best the SP can do is to 
   know that the principal has all these usernames and user IDs and to 
   choose a user ID to track the principal with. 
    
9.2.1   Examples 
    
   In section 7.2.1 two requests were made. The follow example is a 
   response to the first request where the AA refuses to work with the 
   SP for unstated, non-technical reasons. 
    
   <env:Envelope  
    xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'> 
     <env:Body> 
     <z:LookupResponse xmlns:z="zisso:1"> 
       <z:context>This is some context information</z:context> 
       <z:RequestRefused/> 
     </z:LookupResponse> 
     </env:Body> 
   </env:Envelope> 
    

  
Goland                                                              22 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Had the AA refused the second request listed in section 7.2.1 then 
   the response would only have differed in the absence of the context 
   XML element. 
    
   Had the first request succeeded then the response may have looked 
   something like: 
    
   <env:Envelope  
    xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'> 
     <env:Body> 
       <z:LookupResponse xmlns:z='zisso:1'> 
         <z:context>This is some context information</z:context> 
         <z:Success> 
           <z:sp>shoestore.com</z:sp> 
           <z:ip>myip.com</z:ip> 
           <z:username>principal</z:username> 
           <z:userid>http://www.myip.com/users/principal</z:userid> 
           <z:aasessionlength>2002-05-31T13:20:00.000-
   05:00</z:aasessionlength> 
           <z:logoff>http://www.myip.com/logoff</z:logoff> 
         </z:Success> 
       </z:LookupResponse> 
     </env:Body> 
   </env:Envelope> 
    
   It so happens that the principal successfully authenticated both as 
   the username and the user ID that was listed in the original request 
   but the AA choose to only acknowledge the match to the user name and 
   return a different user ID. Therefore the SP only knows about the 
   match against the user name. 
    
   The AA has instructed the SP that the AA's authentication session 
   with the principal and client will expire on the listed date and 
   time. 
    
   The AA also specifies that the principal can logoff from the AA's 
   authentication session by navigating to the listed HTTP URL. The SP 
   can then integrate that URL into the SP's logoff UI. For example one 
   could imagine that after having successfully logged off the SP the 
   SP's final UI might include the text that contains the equivalent of 
   "You have successfully logged off from your authentication session 
   with your SP. If you would like to logoff from your authentication 
   session with your AA then please click here." The link would then 
   navigate the principal to the AA's logoff page and allow the 
   principal to choose to logoff. 
    
9.3.    Explanation 
    
9.3.1   Why aren't the mappings between user names and user IDs 
     required to be clearly identified in the response? 
    
   We probably should. The reason it wasn't included was due to the 
   desire to provide the SP with the absolutely minimum required 
  
Goland                                                              23 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   identifying information. Since SPs are supposed to only track 
   principals using User IDs it seemed reasonable to make it 
   uncomfortable for them to do anything else. 
    
9.3.2   Is the logoff URL enough? Don't we need to specify names and 
     such to make usable UI? 
    
   The implementation text includes sample language for use with 
   logoff, it says "You have successfully logged off from your 
   authentication session with your SP. If you would like to logoff 
   from your authentication session with your AA then please click 
   here." 
    
   Of course it is inconceivable that such awful, obtuse, jargon ridden 
   language would ever be used in a real world UI. The real world UI 
   would want to say something like "Thank you for having visited 
   ShoeStore.Com. If you would like to logoff from MYIP.com the please 
   click here." Only 80% of most users should get confused by this 
   language that is better than the 99.9999% of users who would get 
   confused by the first language. But the second proposed text 
   requires knowing the IP's name (just using their DNS address isn't 
   likely to work well) and probably displaying their logo and other 
   niceties. 
    
   Trying to come up with a standard to handle declaring names, logos, 
   negotiating formats, figuring our if you can just use frames, maybe 
   image tags, etc. in the V1 time frame just seemed silly. So it 
   seemed reason to throw in the logoff URL to cause some thought and 
   perhaps even remove it before we finalize V1. 
    
10.     Use Case Scenarios 
    
10.1.   First Visit 
    
   Principal wishes to use a SP and IP for the first time. We assume 
   that the SP and IP have an existing relationship and have already 
   decided on how to handle matters such as encrypting the requests and 
   responses. 
    
   In this scenario the principal is a human. The principal and client 
   are shown separately so as to illustrate how many times the human 
   principal has to interact with the system. 
    










  
Goland                                                              24 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   Principal   Client               SP    AA    IP   DNS 
       |          |                  |     |     |    | 
       |1.Go to SP|                  |     |     |    | 
       ----------->                  |     |     |    | 
       |          |2.GET on SP addr  |     |     |    | 
       |          ------------------->     |     |    | 
       |          |3.Request IP Addr |     |     |    | 
       |          <-------------------     |     |    | 
       |4.Display Request            |     |     |    | 
       <-----------                  |     |     |    | 
       |5.Enter IP Addr              |     |     |    | 
       ----------->                  |     |     |    | 
       |          |6.Send IP Addr    |     |     |    | 
       |          ------------------->     |     |    | 
       |          |                  |7.NAPTR Lookup for AA Addr 
       |          |                  -----------------> 
       |          |                  |8.AA addr from NAPTR 
       |          |                  <----------------- 
       |          |9.303 to AA Addr + Data |     |    | 
       |          <------------------|     |     |    | 
       |          |10.GET on AA Addr + Data|     |    | 
       |          ------------------------->     |    | 
       |          |11.Request Auth Data    |     |    | 
       |          <-------------------------     |    | 
       |12.Display Request for Auth Data   |     |    | 
       <-----------                  |     |     |    |  
       |13.Fill in Response          |     |     |    | 
       ----------->                  |     |     |    | 
       |          |14.Send Auth Info to AA |     |    | 
       |          ------------------------->     |    | 
       |          |15.303 to SP Addr + Data|     |    | 
       |          <-------------------------     |    | 
       |          |16.GET on SP Addr + Data      |    | 
       |          ------------------->     |     |    | 
       |          |17.Welcome Authenticated Principal | 
       |          <-------------------------     |    | 
       |18.Display Request Page to Principal     |    | 
       <-----------                  |     |     |    | 
    
   1. Go to SP - The principal asks the Client to navigate to a 
   particular SP. 
    
   2. GET on SP Addr - The principal's request is translated into a 
   HTTP GET request on the SP's Addr. Note that this request doesn't 
   have to necessarily be the GET method. 
    
   3. Request IP Addr - The SP responds with UI asking the principal to 
   identify the principal's IP. This could be done by selecting an 
   icon, picking from a drop down, typing in the IP's DNS address, type 
   in the principal's IP affiliated e-mail address or even providing 
   the principal's IP affiliated phone number. Any address that 
   translated into a DNS name will work. 
    
  
Goland                                                              25 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   4. Display Request - The client displays the SP's request (probably 
   a HTML form) to the principal. 
    
   5. Enter IP Addr - The principal responds by typing, clicking, 
   selecting, etc. their IP. 
    
   6. Send IP Addr - The principal's response, probably a standard HTML 
   form submit, is sent to the SP. 
    
   7. The SP performs a NAPTR lookup on the IP's DNS name for the SSO 
   service. 
    
   8. The NAPTR resolution process finishes and the SP gets back the 
   IP's AA address. NOTE: Both 7 and 8 are unnecessary where the SP 
   already knows the IP's AA either due to previous lookups or due to 
   some out of band mechanism. 
    
   9. The SP sends a 303 redirect to the client. The URL to be 
   redirected to consists of the IP's AA address followed by a "?" 
   followed by an encrypted SOAP request asking the AA (on behalf of 
   the IP) to authenticate the user. 
    
   10. The client performs a HTTP GET on the redirected URL. 
    
   11. The AA asks the principal for authentication information. This 
   could be through a HTML Form over TLS, a digest/basic challenge, 
   etc. 
    
   12. The client presents the AA's request to the principal. 
    
   13. The principal fills in the information, which could be a name 
   and password, a token based ID, biometric, etc. In our case it's 
   just a HTML form asking for a name and password. 
    
   14. The client sends the authentication information, in this case a 
   HTML form result, to the AA. 
    
   15. The AA confirms that the principal is who they claim to be and 
   sends a HTTP redirect to the client sending them back to the SP. The 
   redirected URL contains the SP's address (taken from the original 
   SOAP request) followed by a "?" followed by an encrypted SOAP 
   response. The response states that the user is who they claim to be 
   and provides a 'log off' URL that if navigated to will remove all 
   authentication cookies from the client that were put there by the 
   AA. The redirect also probably contains a cookie header setting a 
   cookie on the client specifying that the client has been 
   authenticated for a particular principal. 
    
   16. The client performs a GET on the redirected URL. 
    
   17. The SP decrypts and checks the signature on the SOAP response 
   confirming it's validity. Seeing that the principal is authenticated 
   the SP returns a welcome page. The SP also probably sets a cookie on 
  
Goland                                                              26 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   the client specifying the authenticated principal associated with 
   that client. 
    
   18. The requested page is displayed to the principal. 
    
10.2.   Second Visit 
    
   The authenticated client returns to the SP for another visit. The 
   authentication session is still active. 
    
   Principal   Client               SP    AA    IP   DNS 
       |          |                  |     |     |    | 
       |1.Go to SP|                  |     |     |    | 
       ----------->                  |     |     |    | 
       |          |2.GET on SP addr  |     |     |    | 
       |          ------------------->     |     |    | 
       |          |3.Return Requested Page |     |    | 
       |          <-------------------     |     |    | 
       |4.Display page to Principal  |     |     |    | 
       <-----------                  |     |     |    | 
    
   In this scenario the GET request in step 2 contained a cookie set by 
   the SP on the client specifying that the authenticated principal 
   associated with the client. As the cookie had not expired the client 
   was allowed immediate access. 
    
10.3.   A new SP 
    
   While the principal's authentication session with the AA is still 
   active the principal visits a new SP that the principal has not been 
   to before. 
 
   The message flow is identical to the one given in section 10.1 with 
   the exception of steps 11 through 14. Since the AA's authentication 
   session with the principal/client is still active the AA will skip 
   steps 11 through 14 and go directly to step 15. Therefore the 
   principal need never see any UI from the AA. 
    
10.4.   Third Visit 
    
   Some time later the authenticate client returns again to the SP. But 
   now the authentication session with the SP and the IP has expired.  
    
   The exact nature of the subsequent message flow depends on several 
   factors. The numbers for the steps given below are taken from 
   section 10.1. 
    
   Steps 3 - 6: It is tempting to skip steps 3 through 6 since the SP 
   already knows the IP that the principal used when previously 
   authenticating. If skipping these steps then the principal would be 
   redirected to the AA for authentication (note that steps 7 through 
   10 may still be necessary). What if the principal has decided to 
   change their IP? In that case the authentication dialog from the old 
  
Goland                                                              27 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
   IP's AA won't be very useful. As such SPs that want to skip steps 3 
   to 6 when re-authenticating a principal are urged to use frames or a 
   similar mechanism so that at least part of the screen is still 
   controlled by the SP and will let the principal indicate that they 
   do not wish to be authenticated by their previous IP's AA. 
   Alternative the SP can choose not to skip 3 through 6 and do a full 
   re-login. 
    
   Steps 7 - 8: If the TTL for the cached NAPTR responses haven't 
   expired then these steps can be skipped. 
    
11.     XML Schema 
    
   The XML elements used inside of the SOAP body XML element are 
   defined using the syntax provided by the W3C's XML Schema [5]. 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema targetNamespace="zisso:1" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:z="zisso:1" 
   elementFormDefault="qualified" attributeFormDefault="qualified"> 
     <xs:element name="Lookup" type="z:LookupType"/> 
     <xs:complexType name="LookupType"> 
       <xs:sequence> 
         <xs:element name="sp" type="z:DNSName"/> 
         <xs:element name="ip" type="z:DNSName"/> 
         <xs:element name="username" type="xs:string" minOccurs="0" 
                     maxOccurs="unbounded"/> 
         <xs:element name="userid" type="xs:anyURI" minOccurs="0" 
                     maxOccurs="unbounded"/> 
         <xs:element name="return" type="xs:anyURI" 
                     maxOccurs="unbounded"/> 
         <xs:element name="context" type="xs:anyType" minOccurs="0"/> 
       </xs:sequence> 
     </xs:complexType> 
     <xs:element name="LookupResponse" type="z:LookupResponseType"/> 
     <xs:complexType name="LookupResponseType"> 
       <xs:sequence> 
         <xs:element name="context" type="xs:anyType" minOccurs="0"/> 
         <xs:choice> 
           <xs:element name="Success" type="z:SuccessType"/> 
           <xs:element name="SPSecurityFailure"/> 
           <xs:element name="RequestRefused"/> 
           <xs:element name="SyntaxError"/> 
           <xs:element name="PrincipalAuthFailed"/> 
         </xs:choice> 
       </xs:sequence> 
     </xs:complexType> 
     <xs:complexType name="SuccessType"> 
       <xs:sequence> 
         <xs:element name="sp" type="z:DNSName"/> 
         <xs:element name="ip" type="z:DNSName"/> 
         <xs:element name="username" type="xs:string" minOccurs="0" 
                     maxOccurs="unbounded"/> 
  
Goland                                                              28 
                 Zero Install Single Sign On Solution    November 2001 
                          for a HTTP Browser 
 
         <xs:element name="userid" type="xs:anyURI" 
                     maxOccurs="unbounded"/> 
         <xs:element name="aasessionlength" type="xs:dateTime"/> 
         <xs:element name="logoff" type="xs:anyURI" minOccurs="0" 
                     maxOccurs="unbounded"/> 
       </xs:sequence> 
     </xs:complexType> 
     <xs:complexType name="DNSName"> 
       <xs:simpleContent> 
         <xs:restriction base="xs:string"/> 
       </xs:simpleContent> 
     </xs:complexType> 
   </xs:schema> 
    
   [Ed. Note: Need to define regex for DNS] 
    
12.     Security Considerations 
    
   [Ed. Note: I will put aside six or seven weeks to write this 
   section.] 
    
13.     IANA Considerations 
    
   [Ed. Note: The ZISSO names are just placeholders for the NAPTR 
   resolution service and the URI protocol type.]  
    
14.     References 
 
1  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", BCP 14, RFC 2119, March 1997 
 
2  Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 
Identifiers (URI): Generic Syntax", RFC 2396, August 1998 
 
3  Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource 
Record", RFC 2915, September 2000 
 
4  Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., 
Nielsen, H. F., Thatte, S., Winer, D., "Simple Object Access Protocol 
(SOAP) 1.1", W3C Note, May 2000 
 
5  Thompson, H. S., Beech, D., Maloney, M., Mendelsohn, N., "XML Schema 
Part 1: Structures", W3C Recommendation, May 2001 
    
15.     Author's Address 
    
   Yaron Y. Goland 
   Openwave 
   Email: yaron.goland@openwave.com 




  
Goland                                                              29