Comments regarding x509 authn based attribute profile (draft 4)

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.