Could you send me an I-D or blog post etc. for ActAs?
Over a year ago, I posted this:
http://nat.sakimura.org/2012/08/03/named-token/ and it may be closely
related.
2013/11/1 Anthony Nadalin
> Would like 10 min to discuss ActAs draft
>
> -Original Message-
> From: oauth-boun...@ietf.or
Hi Brian, Hi all,
I read through the SAML Bearer draft and here are a few comments:
(actually some of the comments that I made yesterday regarding
draft-ietf-oauth-jwt-bearer-06)
Section 3:
Item #1: You wrote: "Issuer
values SHOULD be compared using the Simple String Comparison
Hi all,
reading througth various dynamic client registration document I get the
impression that there is one area of potential disconnect, namely in the
end user / developer experience.
When OpenID started this concept that a random IdP could talk to a
random RP it seemed like a great idea.
Hannes,
Some really good, thought provoking comments! I had not really been focused as
much on financial relationships between SP and client. I must confess I
considered web clients that set up major relations with service providers. In
these cases I dismissed them as a use case because they wo
Hannes,
There are a number of major use cases and expectations that I've kept in mind
throughout the development of this protocol. Some of the fallout of this is
captured in appendix B of the current draft, but I'd be happy to write them out
here:
First, the use cases of OpenID Connect and UM
The software statement does make sense and we could use it in BB+ to take the
place of the registration_jwt, even though I'm not really in favor of inventing
yet another mechanism for presenting an assertion to an OAuth-protected
endpoint.
The association draft is in many ways semantically equi
Client assoc is a profile of the existing token endpoint and uses the assertion
drafts definition of client assertion. As such it is not a new mechanism.
Client assoc is also compatible with assertion draft and thus as new token
formats are defined they can automatically be issued via dyn assoc
