OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [no subject]


-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: Tuesday, August 31, 2004 8:44 AM
To: Mishra, Prateek
Cc: Paul Madsen; 'security-services@lists.oasis-open.org'
Subject: RE: [security-services] SessionIndex and Privacy Text



I think it would be useful to document the two common mechanisms used in
liberty solutions for this index:

        a) small integer (which we have in paul's suggested text)
and   b)  the assertion ID itself is stored in the session index.

The second seems to have issues with the "MUST NOT be a unique..."
requirement although it doesn not violate privacy.

So, my recommended verbage:


When privacy is a concen, care must be taken to ensure that the SessionIndex
element does not invalidate other privacy mechanisms - the value MUST NOT be
usable to correlate sessions across different SPs  Two recommended solutions
are provided below: 







*	The authority uses small positive integers (or reoccurring constants
in a list) for the SessionIndex, then it SHOULD choose the range of values
such that the cardinality of any one integer will be sufficiently high to
prevent a particular user's actions from being correlated across multiple
service providers. The authority SHOULD choose values for SessionIndex
randomly from within this range (except when required to ensure unique
values for subsequent AuthnStatements to the same service provider). 

*	The authority uses the Assertion ID value in the Session Index
element.  




*	


	




Hmm... Thinking about this, we could just move to using the assertion ID
since storing that value at the SP is little different than storing the
session index and for the IDP, they probably keep track of the assertion IDs
that they have issued at least for the lifetime of the assertion.

If we did use the Assertion ID, we could simply get rid of the session
index.

Thoughts?

Conor
Mishra, Prateek wrote on 8/30/2004, 4:32 PM: 




+1. We just finished puzzling over the “small integer” suggestion. In any
case, as the proposed text suggests, this issue is relevant only when
privacy is a concern (admittedly often).



- prateek






  _____  

From: Paul Madsen [ mailto:p.madsen@entrust.com
<mailto:p.madsen@entrust.com> ] 
Sent: Wednesday, August 25, 2004 3:26 PM
To: ' security-services@lists.oasis-open.org
<mailto:security-services@lists.oasis-open.org> '
Subject: [security-services] SessionIndex and Privacy Text





Hi, some comments on Lines 977-981 in Core







1) its not clear to me whether this requirement is normative on all
deployments or only on those for which privacy is a issue. The preface 'For
privacy reasons' somewhat gives the impression that this is a general
requirement. This contrasted to potential alternative text e.g. '*When*
privacy is a concern ...'







2) when combined with the previous 'SHOULD be a small, positive integer',
the 'MUST NOT be reused in subsequent assertions
given to different relying parties about the same principal' seems
contradictory







    a) if small integers are used for SessionIndex, then for any reasonable
number of simultaneously logged in users, the high cardinality of the
individual SessionIndex values will prevent their use by rogue SPs for
collusion, i.e. there will so be many users all with SessionIndex of '3'
that no two SPs will be able to use this value to pinpoint a particular
user. This is acknowledged by the last sentence of the para, 'MAY be a small
integer value that is used in assertions issued on behalf of many different
subjects at the same time'. Consequently, the restriction against reuse
seems overconstraining.







I imagine that the MUST NOT reuse rule is motivated by the potential for the
SessionIndex value to be something other than a small integer. We could
differentiate these cases given their different aspects.







    b) if rogue SPs know that the IDP MUST NOT reuse SessionIndex values,
this actually gives them more information than if the IDP were to simply
insert random values (possibly within some defined range) for the
SessionIndex. For instance, if two SPs are comparing logs for a bunch of
users they know were simultaneously logged in at IDP, <AuthnStatement>s with
the same SessionIndex can only be for different users and so can be
discarded.  A bonus would be that the IDP would no longer  need to keep
track of which SessionIndex's were used inter-SP (it would still need to
intra-SP)







My proposed replacement text







When privacy is a concen, care must be taken to ensure that the SessionIndex
element does not invalidate other privacy mechanisms - the value MUST NOT be
a unique value identifying a principal's session at the authority. 







If the authority uses small positive integers (or reoccurring constants in a
list) for the SessionIndex, then it SHOULD choose the range of values such
that the cardinality of any one integer will be sufficiently high to prevent
a particular user's actions from being correlated across multiple service
providers. The authority SHOULD choose values for SessionIndex randomly from
within this range (except when required to ensure unique values for
subsequent AuthnStatements to the same service provider).







if the authority uses some other scheme for the SessionIndex attribute, it
SHOULD choose values for SessionIndex randomly.




 



Paul 



-----------------------------------------------------------------



Paul Madsen



e:   <mailto:p.madsen@entrust.com> p.madsen@entrust.com



p:  613-270-2632



c:  613-799-2632



Entrust









To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php. 


------_=_NextPart_001_01C48F5A.96FF429A
Content-Type: text/html;
	charset="UTF-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<TITLE></TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff size=2>When I 
read thru the Liberty specs, it seem to imply that the session index was a way 
to represent different sessions for a single user. For example, a user using 2 
machines/browsers to log in. Consider the case where a&nbsp;user only logs in 
once at an IDP (assume it gets assigned session index value of 1), and then uses 
that authentication/session at the IDP to authenticate to various other SPs. My 
take from the Liberty specs was that the session index for all the SPs could be 
set to 1. In general if thousands of users log in from a single machine/browser 
only, their session index would have a value 1.</FONT></SPAN></DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2>Eventually, there might be some users that log in from a second machine 
to an IDP (that session index gets the value of 2).&nbsp;From there, they use 
that authentication to get into other SPs (perhaps the same ones as the other 
session or perhaps new SPs -- that is irrelevant). The session index value of 2 
would be used during an authentication response by the IDP for this case. In 
general you might have hundreds of users logged in twice.</FONT></SPAN></DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff size=2>Taking 
this further some users might log in from a third machine/browser, and so 
on.</FONT></SPAN></DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff size=2>So my 
question is, if we use the same session index value for all SPs 
(if&nbsp;the&nbsp;authentication is based on the same IDP session)&nbsp;why is 
privacy an issue. In general, an SP site would see thousands of 1's, hundreds of 
2's, tens of 3's, etc... And because users can go to arbitrary SPs, it is 
extremely unlikely that you can match up these session 
indexes.</FONT></SPAN></DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff size=2>From 
the Liberty specs and from a technical perspective, I took the need for a 
session index as a requirement to be able to logout users on a per 
machine/browser basis. So if the original user browser session above is being 
logged out (session index value of 1), the other session (value of 2), should 
not be affected.</FONT></SPAN></DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593583912-31082004><FONT face=Arial color=#0000ff 
size=2>Thanks, Tom.</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Conor P. Cahill 
  [mailto:concahill@aol.com]<BR><B>Sent:</B> Tuesday, August 31, 2004 8:44 
  AM<BR><B>To:</B> Mishra, Prateek<BR><B>Cc:</B> Paul Madsen; 
  'security-services@lists.oasis-open.org'<BR><B>Subject:</B> RE: 
  [security-services] SessionIndex and Privacy Text<BR><BR></FONT></DIV><FONT 
  face="Comic Sans MS,sans-serif"><FONT size=2><BR>I think it would be useful to 
  document the two common mechanisms used in liberty solutions for this 
  index:<BR><BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; a) small integer (which we 
  have in paul's suggested text)<BR>and&nbsp;&nbsp; b)&nbsp; the assertion ID 
  itself is stored in the session index.<BR><BR>The second seems to have issues 
  with the "MUST NOT be a unique..." requirement although it doesn not violate 
  privacy.<BR><BR>So, my recommended verbage:<BR></FONT></FONT>
  <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT 
  face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>When 
  privacy is a concen,&nbsp;care must be&nbsp;taken to ensure that the 
  SessionIndex element does not invalidate other privacy mechanisms - the value 
  MUST NOT be usable to correlate sessions across different SPs&nbsp; Two 
  recommended solutions are provided 
  below:&nbsp;</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P><FONT 
  face="Comic Sans MS,sans-serif" size=2></FONT><FONT 
  face="Comic Sans MS,sans-serif" size=2></FONT>
  <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><FONT 
  size=3><O:P></O:P></FONT></FONT></P><FONT face="Comic Sans MS,sans-serif" 
  size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
  <DIV>
  <UL>
    <LI><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>The 
    authority uses small positive integers (or reoccurring constants in a list) 
    for the SessionIndex, then it SHOULD&nbsp;choose the range of values such 
    that the cardinality of any one integer will be sufficiently high to prevent 
    a particular user's actions from being correlated across multiple service 
    providers. The&nbsp;authority SHOULD&nbsp;choose values for SessionIndex 
    randomly from within this range (except when required to ensure unique 
    values for subsequent AuthnStatements to the same service 
    provider).</FONT></FONT></FONT></I></EM></FONT> 
    <LI><FONT face="Comic Sans MS,sans-serif" size=2><I><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>The 
    authority uses the Assertion ID value in the Session Index element.&nbsp; 
    <BR><EM></EM></FONT></FONT></FONT></I></FONT></LI></UL><EM></EM><O:P></O:P>
  <UL>
    <LI><FONT face="Comic Sans MS,sans-serif" size=2></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" 
    size=2><EM></EM><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></LI></UL></DIV><FONT face="Comic Sans MS,sans-serif" 
  size=2></FONT><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
  <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT><FONT 
  face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
  face="Comic Sans MS,sans-serif" size=2></FONT><FONT 
  face="Comic Sans MS,sans-serif" size=2></FONT><FONT face="Century Gothic" 
  size=2><FONT face="Century Gothic"><FONT size=2></FONT></FONT></FONT><FONT 
  face="Comic Sans MS,sans-serif"><FONT size=2><BR>Hmm... Thinking about this, 
  we could just move to using the assertion ID since storing that value at the 
  SP is little different than storing the session index and for the IDP, they 
  probably keep track of the assertion IDs that they have issued at least for 
  the lifetime of the assertion.<BR><BR>If we did use the Assertion ID, we could 
  simply get rid of the session index.<BR><BR>Thoughts?<BR><BR>Conor<BR><SPAN 
  type="cite">Mishra, Prateek wrote on 8/30/2004, 4:32 PM:</SPAN> </FONT></FONT>
  <P><FONT face="Comic Sans MS,sans-serif" size=2></FONT></P>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid" 
  type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV class=Section1><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face=Arial color=blue size=3><FONT face=Arial><FONT 
    size=3><FONT color=blue><FONT color=blue>+1. We just finished puzzling over 
    the “small integer” suggestion. In any case, as the proposed text suggests, 
    this issue is relevant only when privacy is a concern (admittedly 
    often).<O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face=Arial color=blue size=3><FONT face=Arial><FONT 
    size=3><FONT color=blue><FONT 
    color=blue><O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face=Arial color=blue size=3><FONT face=Arial><FONT 
    size=3><FONT color=blue><FONT color=blue>- 
    prateek<O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face=Arial color=blue size=3><FONT face=Arial><FONT 
    size=3><FONT color=blue><FONT 
    color=blue><O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
    face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
    <HR tabIndex=-1 align=center width="100%" SIZE=2>
    </SPAN></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><B><FONT 
    face=Tahoma size=2><FONT face=Tahoma><FONT 
    size=2>From:</FONT></FONT></FONT></B></FONT><FONT face=Tahoma size=2><FONT 
    face=Tahoma><FONT size=2> Paul Madsen [<A class=moz-txt-link-freetext 
    href="mailto:p.madsen@entrust.com";>mailto:p.madsen@entrust.com</A>] 
    <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, August 
    25, 2004 3:26 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
    <ST1:PERSONNAME w:st="on">'<A class=moz-txt-link-abbreviated 
    href="mailto:security-services@lists.oasis-open.org";>security-services@lists.oasis-open.org</A>'</ST1:PERSONNAME><BR><B><SPAN 
    style="FONT-WEIGHT: bold">Subject:</SPAN></B> [security-services] 
    SessionIndex and Privacy Text</FONT></FONT></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>Hi, some&nbsp;comments on Lines 977-981 
    in Core</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>1) its not clear to me whether this 
    requirement is normative on all deployments or only on those for which 
    privacy is a issue. The preface 'For privacy reasons' somewhat gives the 
    impression that this is a general requirement. This contrasted to potential 
    alternative text e.g. '*When* privacy is a concern 
    ...'</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>2) when combined with the previous 
    '</FONT></FONT></FONT><FONT face=ArialMT size=2><FONT face=ArialMT><FONT 
    size=2>SHOULD be a small, positive integer', </FONT></FONT></FONT><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>the 
    'MUST NOT be reused in subsequent assertions<BR>given to different relying 
    parties about the same principal' seems 
    contradictory</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>&nbsp;&nbsp;&nbsp; a) if small integers 
    are used for SessionIndex, then for any reasonable number of simultaneously 
    logged in users, the high cardinality of the individual SessionIndex values 
    will prevent their use by rogue SPs for collusion, i.e. there will so be 
    many users all with SessionIndex of '3' that no two SPs will be able to 
    use&nbsp;this value&nbsp;to pinpoint a particular user. This is acknowledged 
    by the last sentence of the para, 'MAY be a small integer value that is used 
    in assertions issued on behalf of many different subjects at the same time'. 
    Consequently, the restriction against reuse seems 
    overconstraining.</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>I imagine that the MUST NOT reuse rule is 
    motivated by the potential for the SessionIndex value to be something other 
    than a small integer. We could differentiate these cases given their 
    different aspects.</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>&nbsp;&nbsp;&nbsp; b) if rogue SPs know 
    that the IDP MUST NOT reuse SessionIndex values, this actually gives them 
    more information than if the IDP were to simply insert random values 
    (possibly within some defined range)&nbsp;for the SessionIndex. For 
    instance, if two SPs are comparing logs for a bunch of users they know were 
    simultaneously logged in at IDP, &lt;AuthnStatement&gt;s with the same 
    SessionIndex can only be for different users and so can be discarded.&nbsp; 
    A&nbsp;bonus would be that the IDP would no longer&nbsp; need to keep track 
    of which SessionIndex's were used inter-SP (it would still need to 
    intra-SP)</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>My proposed replacement 
    text</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>When 
    privacy is a concen,&nbsp;care must be&nbsp;taken to ensure that the 
    SessionIndex element does not invalidate other privacy mechanisms - the 
    value MUST NOT be a unique value identifying a principal's session at the 
    authority.&nbsp;</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>If the 
    authority uses small positive integers (or reoccurring constants in a list) 
    for the SessionIndex, then it SHOULD&nbsp;choose the range of values such 
    that the cardinality of any one integer will be sufficiently high to prevent 
    a particular user's actions from being correlated across multiple service 
    providers. The&nbsp;authority SHOULD&nbsp;choose values for SessionIndex 
    randomly from within this range (except when required to ensure unique 
    values for subsequent AuthnStatements to the same service 
    provider).</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT 
    face="Century Gothic" size=2><FONT face="Century Gothic"><FONT size=2>if 
    the&nbsp;authority uses some other&nbsp;scheme for the SessionIndex 
    attribute, it SHOULD&nbsp;choose values for SessionIndex 
    randomly.</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2><BR></FONT></FONT></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2>&nbsp;<O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Century Gothic" size=2><FONT 
    face="Century Gothic"><FONT size=2>Paul&nbsp;</FONT></FONT></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" 
    size=2><STRONG><B><FONT face=Arial size=2><FONT face=Arial><FONT 
    size=2>-----------------------------------------------------------------</FONT></FONT></FONT></B></STRONG><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" 
    size=2><STRONG><B><FONT face="Bookman Old Style" size=2><FONT 
    face="Bookman Old Style"><FONT size=2>Paul 
    Madsen</FONT></FONT></FONT></B></STRONG><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT 
    face="Bookman Old Style"><FONT size=2>e:&nbsp; </FONT></FONT></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2><A 
    href="mailto:p.madsen@entrust.com";><FONT face="Bookman Old Style" 
    size=2><FONT face="Bookman Old Style"><FONT 
    size=2>p.madsen@entrust.com</FONT></FONT></FONT></A><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT 
    face="Bookman Old Style"><FONT size=2>p:&nbsp; 
    613-270-2632</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT 
    face="Bookman Old Style"><FONT size=2>c:&nbsp; 
    613-799-2632</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" 
    size=2><O:P></O:P></FONT></P><FONT face="Comic Sans MS,sans-serif" 
    size=2></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT 
    face="Bookman Old Style"><FONT size=2>Entrust</FONT></FONT></FONT><FONT 
    face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT>
    <DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></DIV><FONT 
    face="Comic Sans MS,sans-serif" size=2></FONT></BLOCKQUOTE>To unsubscribe from 
  this mailing list (and be removed from the roster of the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php. 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C48F5A.96FF429A--


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]