1. Core Assertions Phill Hallam-Baker

2. Status Waiting for use cases to specify problem Can give a price of specific use case features –Auth-XML / S2ML / X-TASS / ITML … Whose method is best is not the issue at this point –Number of communications absolutely necessary Fewer is better –Data flow  Communication Graph –Re-use of data structures

3. Decision Process (Coh-Ad Model) Divide Decisions into 3 types: 1) Nobody cares (very much) Tag names, structure nesting etc. Everyone has to burn their code anyway 2) Objective design issues Protocol efficiency etc. Discuss 3) Subjective design tradeoff decisions Identify costs / benefits of alternate approaches Send to full group

4. Data Structures Identified Thus Far Assertion –Authenticated statement Ticket / Assertion Token –Compact reference to an assertion –Strong cryptographic binding

5. Parties Issuer Client Relying  May not support Assertions / SAML ‘64 byte boundary’ ‘Distributor’‘Enforcer’

6. Pull Model Issuer Client Relying    

7. V Model Issuer Client Relying   

8. Proxy Model Issuer Client Relying  

9. “Must be a Plumber” Amalgamated Plumber’s Union “Alice is a Plumber” Multiple Issuer Model Client Relying Issuer

10. Assertion Data Structure Assertion Identifier - URI Status –Valid | Invalid | Indeterminate Authorization(s) Subject Identifier –Authentication Data Conditions –Validity Interval –Other Essential Conditions When / how to get an update [Optional]

11. Authorizations Option 1: Shared Vocabulary of Terms –URI – the Web way to do this URL – Can identify the actual resource [I.e. AuthZ Decision] –OK to access http://xyz.test/dead_secret.html URN – Can encode rights [I.e. Constrained AuthZ Attribute] –Need mechanism to map rights to resources –SAML need not define this [Decoupled] Option 2: Private Extension Schema –For data more structured than URN allows [I.e. Unconstrained AuthZ Attributes] Fat Controller …

12. Subject / Authentication Data Identification Essential –Bind assertion to authentication data ‘Holder of this ticket has these authorizations’ ‘Holder of this public key has these authorizations’ ‘Holder of this account (i.e. reference to password) has these authorizations’ Useful (in some circumstances) –Bind assertion to identity ‘Alice has these authorizations’

13. Note on Multiple Issuer Case Deliberately avoid committing Assertion structure to particular level of granularity –Leave this to implementation –Does not introduce ambiguity –Reduces number of data structures required –Allows great flexibility

14. Conditions  Validity Interval –| notBefore  notOnOrAfter ]  Audience –Assertion statement may be directed to specific audience –Address the legal issue of relying party problem & good hygiene  Verification Requirement –MUST get positive affirmation per use  Unsupported Condition [Privately defined] –MUST consider assertion status to be Indeterminate –Ensure that applications do not rely on private conditions

15. Reissue [Optional] Specify reissue time & locations –| Earliest  Latest ] –Locations Used for pull / polling model Optional –Issuer does not need to generate –Relying that does not support can ignore

16. Discrete Increase In Complexity Session Management Support “Forced Log Out”

17. Session Management What does it mean for assertion? –Assertion status becomes invalid before expiry Why is this a challenging problem? –How to notify parties relying on on assertion Efficiency Robustness Push or Pull model??? It is a solved problem however (sort of) –PKIX CRLs / Delta CRLs / Scoped CRLs / OCSP –Don’t invent new mechanism – its probably patented

18. Push IssuerRelying Alice is Fired Revoke Alice Authorizations Problem, what if Message does not get through?

19. Pull IssuerRelying Alice is Fired Alice OK? Fired Problem – Efficiency Can we cache response? Can we aggregate?

20. X-TASS Meta Assertions Identify assertion by URI –Define lexical ordering on URIs Meta assertion may specify status of one assertion or a group of assertions –Combine OCSP token and CRL concept –Scope of meta assertion is entirely arbitrary Chosen at time meta assertion is generated C.f. CRL length increases with certificate population

21. X-TASS Meta Assertion Status List IndeterminateValidhttp://abc.test/0412 http://abc.test/0134http://abc.test/0634 http://abc.test/0012 http://abc.test/0145 http://abc.test/0424 http://abc.test/0612 ValidFalse Valid Invalid True http://xyz.test/2832http://xyz.test/9283ValidTrue Is also an assertion: Specify validity interval Specify re-issue schedule

22. XTASS Status Not currently in standards group process –Willing to relinquish change control –Dependency issues – other specifications will use XTASS framework SAML uses 85% of X-TASS feature set –Remaining feature is management of embedded root keys Trust root embedded in device is P A –Secret key S A lives in safe Once a year, an online key P B is established –Delegation Assertion authorizing S B is created This feature could be specified in separate group

23. Ticket Means of referencing assertion –Opaque to clients –Must be capable of embedding in URL, Cookie 64 bytes  256 bytes with base64 encoding Authentication token –The token itself [if always passed over encrypted channel] –Data encrypted in token

24. Typical Ticket Data Items Hash of Assertion ID20 bytes –Need to resolve somehow Locator (URL) of Assertion32  64 bytes –Need some compression mechanism Account ID8  16 bytes –Flag as authenticated / not authenticated Validity Interval10 bytes Any Assertion Field??? bytes Authentication Field20 bytes

25. Ticket Encoding Scheme Should have one –Probably needs to be flexible –Must have minimal overhead Use ASN.1? –Complex, verbose, Mad, Bad, Dangerous to know Binary XML encoding? –Define tag dictionary –MUST be encoded / decoded using one pass decoder

26. Possible scheme Data Item Encoding –Tag Length Value Structure Encoding [if required] –Tag Data End TEStructure LTDataLT LT

27. Encoding of Tags, Length Values Most tags, values encoded in one byte –Unlikely to have > 128 Tags –Unlikely to have data length > 128 –But corner cases may require this Use MSB to indicate extension status, little-endian –80= 0= 0 H –81= 1= 0 H –FF= 127= 7F H –00 81= 128= 00 H + 01 H 80 H –7F FF= 16382= 7F H + 7F H 80 H –Etc. as required

28. Conclusions Have mechanism to meet requirements raised thus far