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

 


Help: OASIS Mailing Lists Help | MarkMail Help

imi message

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


Subject: Re: [imi] Clarifications to the spec to discuss for our call onThursday


<snip>
On 7-Jan-09, at 5:17 PM, Michael McIntosh wrote:

John Bradley <jbradley@mac.com> wrote on 01/07/2009 02:21:00 PM:
>
> <inline>
> On 7-Jan-09, at 1:18 PM, Michael McIntosh wrote:
>
> > John Bradley <jbradley@mac.com> wrote on 01/07/2009 11:00:04 AM:
> >
> > <snip>
> > >
> > > However a IP/STS trusting a PPID coming from a selector has always
> > > made me a bit nervous.   I could as an example modify the Higgins
> > > selector to send arbitrary PPID values in a RST.  If the IP/STS say
> > > Verisign blindly includes it in its signed response the RP checking
> > > the PPID and sig as it would for a p-card could be spoofed if it was
> > > relying solely on those two values.
> > >
> > > Including a pre-calculated PPID may make some IP/STS lazy and not
> > > calculate it themselves when they clearly can.
> > >
> > > Minimally I think the PPID coming from the selector should be used
> > > as input to some other hash function to at-least make spoofing  
> > more difficult.
> > >
> > > I know the spec allows for using the PPID as input to a custom
> > > function,  but I have never seen an explanation of why that is a  
> > good idea.
> > >
> > > I am OK with always including the PPID in the request if someplace
> > > we document the security issues around PPID in m-cards.
> >
> > In order for the IdP to compute the PPID, it needs to know the RP ID.
> > A user may not want to tell the IdP the name of every site they visit.
> >
> Agreed that is why we have the two options though they are at the  
> discretion of the card issuer not the user.


Not completely.
The IdP (AKA Card Issuer) gets to specify whether the RP identity is required, not required, or optional - and that information is in the card and/or IdP metadata (I forget which).
The RP gets to specify whether or not a specific IdP is required, or whether any is acceptable.
The user gets to select which card (and therefore which IdP) will be used.

If a user does not want to use a card that requires disclosure of RP identity to the IdP, it can choose another card.
If the only cards the user has that match the RP policy are cards that require RP disclosure, the user can go elsewhere. 

As far as I know there is nothing in the selector that tells the user that it is going to disclose the identity of the RP to the IdP.

So I agree that in principal the user is free to select any card that matches the required claims but if they have two cards one auditing and one not they have no easy way to distinguish between them.

I have to go back and look at how optional auditing mode works that is a new one to me.

As near as I can see with current selectors the power is in the hands of the IdP,  unless I am missing something.

=jbradley

 

smime.p7s



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