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


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]