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


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

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

Subject: RE: [amqp] AMQP CBS Status

Tokens are generally opaque and are usually based on some prior OOB agreement and exchange of secrets between the relying party (token target) and the issuer. I really donât want to be more specific in the spec than we are here, since itâs not this mechanismâs business to know. The mechanism simply moves opaque stuff.


Regarding the token types, the spec enumerates âcommon token typesâ but that doesnât preclude using others and doesnât mean you need to support any of them and maybe we should clarify that.


From: Rob Godfrey <rgodfrey@redhat.com>
Sent: Friday, February 8, 2019 1:29 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] AMQP CBS Status




On Fri, 8 Feb 2019 at 13:09, Clemens Vasters <clemensv@microsoft.com> wrote:



Iâve looked through the AMQP CBS spec once again and Iâm actually quite happy with it as it stands for the purpose of client authorization at a container, and I propose we start the process of turning it into a committee spec.



It's been a long time since I looked at this... my main question is really whether we need to go into more detail about the form of the tokens.  The document says things like "Before the Client establishes a link or sends messages to âq1â, it puts a token with the appropriate claims conferring âsendâ permission to âq1â on the CBS Node, and verifies its successful disposition. Tokens can be put at any time, and expiring tokens can be replaced at any time."  What is "appropriate", how does the client know the form of token required?  Moreover we define at least three token types - are we saying that every party must support all three, any one of the three, none at all?  How is that information conveyed.


-- Rob 


I believe we will then need a further complementary spec for authorization in federation scenarios that answers questions like:


  • How does authorization work for establishing links through intermediaries? Is there a token attached to the link and is that being propagated?
    • At the intermediary?
    • At the ultimate link destination?
  • How does authorization work for message based routing? Is there a token attached to the message?
    • At the intermediary?
    • At the ultimate message destination?
  • How do we attach tokens to AMQP URIs as a parameters?






Clemens Vasters

Messaging Platform Architect

Microsoft Azure

Ã+49 151 44063557

*  clemensv@microsoft.com   
European Microsoft Innovation Center GmbH | GewÃrzmÃhlstrasse 11 | 80539 Munich| Germany
GeschÃftsfÃhrer/General Managers: Keith Dolliver, Benjamin O. Orndorff 
Amtsgericht Aachen, HRB 12066






Red Hat GmbH, 
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

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