So with what little feedback I've gotten, I'm proposing to add text from
the proposed webfinger and OIDC drafts for the hash-based localization
of strings, with the following properties:
* All localized versions of fields are fully optional on both client and
server
* If a localized version of a
Seems reasonable to me.
On Wed, Mar 13, 2013 at 10:22 AM, Justin Richer jric...@mitre.org wrote:
So with what little feedback I've gotten, I'm proposing to add text from
the proposed webfinger and OIDC drafts for the hash-based localization of
strings, with the following properties:
* All
Having looked at the results yesterday, I'd appreciate it if each you that
already supplied data about your implementations could also answer these
additional questions. All are intended to give more insight into extensions
defined and used. (In many cases, I recognize that your answers will
And one more question...
What additional response_type values do you define, and what do they do?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Wednesday, March 13, 2013 12:08 PM
To: Justin P. Richer; Chuck Mortimore; Todd W Lainhart
SAML supports a couple of SAML assertion reference formats, wherein
assertions are passed by reference.
One format is the artifact, which can be carried by a
saml:artifactthisisanartifactsaml:artifact element
Another possibility is the SAML URI binding which supports references of
the form
It is a direct connection and not a browser redirect. I don't think there is
much value in supporting something like artifact.
On 2013-03-13, at 4:13 PM, prateek mishra prateek.mis...@oracle.com wrote:
SAML supports a couple of SAML assertion reference formats, wherein
assertions are passed
I also don't think there's much value to it. Practically relative to the
additional complexity it'd bring along for the ride.
On Wed, Mar 13, 2013 at 4:17 PM, John Bradley ve7...@ve7jtb.com wrote:
It is a direct connection and not a browser redirect. I don't think there
is much value in
