+1
Additionally, RFC 6749 states it SHOULD only be passed in the body as a last
resort and only if using the HTTP Authorization header is NOT possible.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Xing #E
Dunwoody, GA 30338-8221
Phone: (949
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Xing #E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:<mailto:donald.cof...@reminetworks.com>
donald.cof...@reminetworks.com
From: Brian Campbell [mailto:
+1 for “OAuth 2.0 Authorization Server Discovery”
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Xing #E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:<mailto:donald.cof...@reminetworks.com>
donald.cof...@reminetworks.com
ng.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Xing #E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:<mailto:donald.cof...@reminetworks.com>
donald.cof...@reminetworks.com
From: Nat Sakimura [mailto:sakim...@gmail.co
of
updating the specification to use OAuth 2.0. The industry OpenADE Task
Force, which is the technical WG of the UCAIug, defined additional
information be returned with the OAuth 2.0 Token Response that includes the
URI of the resource to which the AT can be used.
Best regards,
Don
Donald F
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From: Bill Mills [mailto:wmills_92
by another AS (which is
possible using Justin’s use case)?
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
Pedro,
Although the registry could be changed to support the new type format, how is
that any different than adding a new grant_type, such as grant_type=token_swap
or grant_type=swap?
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA
a backwards compatibility
issue for many implementations.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
2335 Dunwoody Crossing Suite E
Dunwoody, GA 30338-8221
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday
Stephen,
I feel it should be MANDATORY to implement TLS1.2, especially since NIST is
in the process of deprecating TLS1.0 as a supported version.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636
both the complexity of the access tokens as well as
make their usage harder to explain to non-technical individuals who have to
understand the differences between the access tokens obtained through the
various flows.
Just my two cents.
Best regards,
Don
Donald F. Coffin
Founder/CTO
See my comments inline [DFC]
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From
The issue I have with not providing Dynamic Registration capability within
OAuth (as the current document proposes) is that to provide a Dynamic
Registration capability will then require the implementation of an additional
standard to provide such support.
At the present time, I am
would vote for B as I believe it clarifies intention of the field, but am
also satisfied if A is the final result.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email
with client application
information.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
-Original Message-
From: Mike Jones [mailto:michael.jo
to access resources, which
IMHO is incorrect based on the RFC 6749 definition in section 4.4.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From: Tim Bray [mailto:twb
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From: Mike Jones [mailto:michael.jo
Justin,
Thanks for the clarification.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
implementation suggestion?
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From: Torsten
or existing draft,
then it must be an out-of-band customized implementation.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
Thanks for the clarification.
I was not envisioning the end-user directly referencing the token revocation
endpoint. The question is how does the end-user know the client did in fact
revoke a token using the token revocation endpoint.
Best regards,
Don
Donald F. Coffin
Founder/CTO
regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
___
OAuth mailing list
OAuth@ietf.org
https
Mike,
Thanks for the information.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
Justin,
Thanks for the information.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
this is an oversight and am merely
pointing out that it needs to be included.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
-Original Message-
From
Does the term Active help clarify the meaning but still confirm to your
intention, Justin?
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof
introspective WG feels scope should be a
JSON array, then the WG should define a new data element rather than
changing the definition of an existing data element already defined by
RFC6749.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa
Hi Torsten,
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof...@reminetworks.com
donald.cof...@reminetworks.com
From: Torsten Lodderstedt
and not relevant
to a specification, especially since RFC 6749 has already set a
documentation precedent..
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email
George,
Thanks for the quick response. I've added my comments after your responses
below.
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email:mailto:donald.cof
33 matches
Mail list logo