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] Token profile issue with AppliesTo and AudienceRestriction


Hi Anthony

the answer is this is that the STS should have a boolean policy which is 
"conform to user request" or "downgrade user request" and depending upon 
the setting of this, it will either reject the request for 50 days or 
issue it for 50 days. This policy will apply to all parameters of the 
request. The point is that the behaviour of the STS should be predicable 
  and configurable by policy

regards

David


Anthony Nadalin wrote:
> Not sure what a well behaved STS really is, as you can take the case 
> where an entity requests a token with a life span of 100 days, but the 
> STS policy is max life span at 50 day, does the STS fault and return 
> nothing or return a RSTR with a token that has a life span of 50 days? 
> WS-Trust was made flexible to abide by policy that can be used to guide 
> the RST and RSTR.  
> 
>  
> 
> *From:* John Bradley [mailto:jbradley@mac.com]
> *Sent:* Tuesday, December 15, 2009 6:07 PM
> *To:* Anthony Nadalin
> *Cc:* Mike Jones; 'imi@lists.oasis-open.org'
> *Subject:* Re: [imi] Token profile issue with AppliesTo and 
> AudienceRestriction
> 
>  
> 
> So if a Issuer gives a user a SAML 1.1 auditing mode card and the 
> selector properly sends the RequiresAppliesTo, it would be OK for the 
> STS to ignore that and perhaps send a different token type than 
> requested eg SAML 2.0 with no audience restriction?
> 
>  
> 
> I can see the server ignoring a token type in the RST if it doesn't 
> support that token type and the user agent is broken.
> 
>  
> 
> Completely disregarding the meta-data from the card seems a touch 
> excessive.  It probably makes more sense in the WS-Fed case.
> 
>  
> 
> The ICAM profile assumes the STS is well behaved, and attempted not to 
> duplicate the spec itself.
> 
>  
> 
> If the specs don't require the STS to honour the RST then we will need 
> to revisit the IMI profile, unless the SAML 1.1 profile covers it.
> 
>  
> 
> John B.
> 
>  
> 
> On 2009-12-15, at 9:53 PM, Anthony Nadalin wrote:
> 
> 
> 
> The STS (WS-Trust) is under the model that the Server Makes Right, just 
> because the RST has it there is ZERO guarantee that the RSTR will 
> reflect any of the RST
> 
>  
> 
> *From:* John Bradley [mailto:jbradley@mac.com] 
> *Sent:* Tuesday, December 15, 2009 11:22 AM
> *To:* Mike Jones
> *Cc:* 'imi@lists.oasis-open.org <mailto:'imi@lists.oasis-open.org>'
> *Subject:* Re: [imi] Token profile issue with AppliesTo and 
> AudienceRestriction
> 
>  
> 
> The wsp:AppliesTo element in the RST is set by the user agent based on 
> the card.
> 
>  
> 
> The issuer has three choices 11.7
> 
>  
> 
> The Issuer has complete control over everything but the optional case.
> 
>  
> 
> I think if the issuer has issued a Auditing or Auditing optional card 
> they MUST honour the ic:RequireAppliesTo in the RST.
> 
>  
> 
> If that is not a requirement of the SAML 1.1 tokens I will need to 
> revisit the ICAM profile.
> 
> We would need to make it a requirement if it is not covered in the IMI spec.
> 
>  
> 
> We say the card must have the ic:RequireAppliesTo, I don't think we 
> called out that the STS must honour it.
> 
>  
> 
> If the RP issues unscoped tokens it shouldn't issue cards that say they 
> support scoped tokens.
> 
>  
> 
> John B.
> 
> On 2009-12-15, at 3:13 PM, Mike Jones wrote:
> 
> 
> 
> 
> The SAML 2.0 token profile currently says:
> 
> If the request contains a <wsp:AppliesTo> element, then 
> a <saml:AudienceRestriction> containing a <saml:Audience> element MUST 
> be included with the value of that element.
> 
>  
> 
> As part of the review of the draft SAML 1.1 token profile, Arun Nanda 
> commented:  “This is overkill IMO. If an IdP is an open IdP that issues 
> ‘unscoped’ tokens for consumption by any RP, it should not be forced to 
> encode an audience in the issued token just because the request included 
> it. So, may be SHOULD is preferred here…”
> 
>  
> 
> I tend to agree with Arun.  I think we should make this change.  That’s 
> the language I’m using in the 1.1 profile.  After discussion, I’ll file 
> an issue about this too.
> 
>  
> 
>                                                                 -- Mike
> 
>  
> 
>  
> 
>  
> 

-- 
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between 
the official stances of the Israeli military and events on the ground.

See  http://www.shovrimshtika.org/news_item_e.asp?id=30

The Israeli government defies Obama, and continues its settlement expansion

Israel plans to allocate $250 million over the next two years for 
settlements

http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Content_ID=698

whilst simultaneously continuing to bulldoze Palestinian homes

http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KEY=27357

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************


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