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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: RE: [xri-editors] further thinking on mustUnderstand


Both of these cases seem to argue for MustUnderstand semantics on an
Authority element, not on the XRID which can describe multiple
authorities. In the second case especially, a client shouldn't be
precluded from processing Service elements just because he doesn't
understand how to pass proper credentials to some resolution authority.
Is that correct?

Dave

-----Original Message-----
From: Peter C Davis [mailto:peter.davis@neustar.biz] 
Sent: Friday, February 04, 2005 9:12 PM
To: xri-editors@lists.oasis-open.org
Subject: [xri-editors] further thinking on mustUnderstand

On todays editor's call, we (I) proposed a usecase where mustUnderstand
may be 
relavant:

Consider the case where extension to the resolution spec require
security 
tokens in order to process/authorize (some) portion of a resolution.
These 
tokens may be resolver tokens, or tokens provided by Authorities, in
order to 
allow downstream authorities to make authorization decisions for
resolution 
response.  It would be required:

- that a lookAhead resolver be able to personify the resolver for
look-ahead 
requests (and thus MUST understand the security tokens provided by the
client 
in order to provide proper resolution services.

- that a client MUST understand tokens provided to them from an
authority, 
which are necessary to perform the next-level resolution to another
authority 
(outside the 2nd level authorities normal trust boundary).

now granted this is a hypothetical (by to me at least, reasonable)
scenario 
that provisions for mustUnderstand would need to be employed...

In protocol SOAP bindings, these relate to processing requirements of
the 
s:Header, and we have no such 2-part messaging in XRI resolution,
however, in 
SOAP, the sorts of tokens passed as above, are placed in the header.

In the case of XRI Res, these tokens would need to be extracted from the
XRID, 
and placed into the HTTP(S) header.  kinda odd, but that's one of the 
challenges with REST ;-).

WS-Trust and Liberty specs have these token profiles, and use them
often... i 
think this design pattern is a good one to follow.

this message aims to:
a] spurning further dialog on the subject, resulting in
b] closure on this issue.

--- peterd

BTW: there may be usecases such as these in trusted resolution, but i
have not 
thought that through just yet.

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/xri-editors/members/leave_w
orkgroup.php.


-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.302 / Virus Database: 265.8.5 - Release Date: 2/3/2005
 


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