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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: RE: [xri] Initial feedback on wd-10-ed-08


Gabe,

 

Agreed completely. It’s funny that the message from you proposing using “saml+https” got caught in an overly aggressive spam filter on this temp machine I’m using so I hadn’t even seen in when I proposed “https+saml”.

 

I like the idea the trust parameter taking multiple values separated by + signs.

 

I have this on the agenda for the 4pm call so we’ll close on it there.

 

=Drummond

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, March 09, 2006 1:16 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: [Norton AntiSpam] RE: [xri] Initial feedback on wd-10-ed-08

 

The only issue with defining saml+https as a value is that we have said all along that we want to make this extensible. Instead of defining just a single value, I'd be happier by defining a pattern (ie +-separated list). That way, when we come up with new trust mechanisms, we can define the string and use it in combo with https or saml. For example, Johannes Ernst has been proposing a simplified digsig mechanism (XML-RSig, I think) and if that were to gain traction, I could forsee us defining a new trusted rez mechanism which allowed for XML-RSig. I'd like to be then able to specify that in the list of trust values: trust=saml-rsig+https   or   trust=saml+saml-rsig+https

 

Got my drift?

 

   -Gabe

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, March 09, 2006 12:26 PM
To: Wachob, Gabe; xri@lists.oasis-open.org
Subject: RE: [xri] Initial feedback on wd-10-ed-08

 

As for the question of the trust parameter value being able to be both saml and https, I *knew* you were going to ask this – I had already put this on the agenda for today’s call. It seems like an obvious enough option, and one which we can easily add to section 6.2 on SAML Trusted Authority Resolution.

 

I reread RFC 2045 and could not find any direction about using the same parameter twice. To be safe, though, we should probably define a fourth value for the trust parameter (after “none”, “https”, and “saml”) of “https+saml”.

 

Do you agree? We can discuss further on today’s call. I’m prepping the agenda right now.

 



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