Comments regarding x509 authn based attribute profile (draft 4)

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Title: Message

Rick, here are the comments on the April 14 draft I mentioned on the SSTC call.

 

 

1. (line 59) s/./../  

 

2. (line 77) change font of <Subject> (second instance of it).

 

3. (line 78) s/NameIdentifier/<NameID>/

 

4. (line 78) s/certificate./certificate and a Format with the value of urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName./ 

 

5. (line 90) s/5 and 6/2 and 3/  

 

6. (line 93) The Basic Mode header is missing.

 

7. (line 109-110) same comment as #2, #3, and #4 above.

 

8. (line 114) Missing header "<Response> Usage"

 

9. (line 119) The font for "The" and "element" is wrong.

 

10. (line 106, line 113, line 145, line 176) What reference to SamlProf in section 6 are you referring to?

 

11. (line 104) s/./../  

 

12. (line 144) s/Assertion/Attribute/

 

13. (line 146) bold font for "SSL3"

 

14. (line 151) same comment as #3 and #4

 

15. (line 153-154) s/providier over the request/provider/

 

16. (line 169) The header is indented one too many.

 

17. (line 168) Delete this line as this is implicit.

 

18. (line 175) s/Assertion/Attribute/

 

19. (line 177) bold font for "SSL3"

 

20. (line 177) add rfc 3280 in bold font for TLS reference as in line 146.

 

21. (line 189) s/provider./provider over the assertion./  

 

22. (line 190) s/AudienceRestrictionCondition/AudienceRestriction/ 

 

23. (line 196, line 202) reverse these 2 sections. I.e., enc before signing to align with Base mode.  

 

24. (line 201) Delete this line as this is implicit.

 

25. (line 206) Font issue with "principal".

 

26. (line 207) If the request comes in with an Encrypted Key (so the SP is creating a new sym key), let's assume the response is such that the IDP does NOT sent an EncryptedKey (but only Encrypted Data). Does this mean the IDP uses the previously established symmetric key (i.e., the one set up out of band). or is it using the EncryptedKey sent in by the SP? Seems that it can be ambiguous.

 

27. (lines 211-214) Update this paragraph so the wording is simlar to lines 164-167.

 

28. (line 223) s/cache user/ cache, to a peristent store, user/   and  s/in cache files/in cache files when associating it with user attributes/   Perhaps you need to explain what "identity of the prinicipal" means. Are you saying do not store the subject DN in readable format? Also, what is readable (so if it is base64 encoded that's ok)?

 

29. (line 229, line 230, line 344) Change to using OASIS standard docs instead of drafts.

 

30 (line 294) Update date to 2005. This is required in the footer as well.

 

 

Tom.