Title: RE: [saml-dev] SAML artifact source id config.
I have
been using a hex representation for source ID in my configuration
file. Entering a source ID and converting it to the byte sequence are
straightforward.
--
Charles
-----Original Message-----
From: Hal Lockhart
[mailto:]
Sent: Thursday, April 18, 2002
2:26 PM
To: 'Chen, Fred'; Mishra, Prateek; Hal Lockhart;
''
Subject: RE: [saml-dev] SAML
artifact source id config.
I
would think that hex would be most convenient. This would make it easy for an
operator to enter a number given in binary, decimal or hex. The usual reason
for using base64 is to reduce the transmission size, which does not apply in
this case.
Hal
-----Original Message-----
From: Chen, Fred
[mailto:]
Sent: Thursday, April 18, 2002 5:19
PM
To: Mishra, Prateek; 'Hal Lockhart';
''
Subject: RE: [saml-dev] SAML
artifact source id config.
Hal explains the right reason for this
discussion:
"the destination site will maintain a table of
SourceID values "
"This information is communicated between the
source and destination sites out-of-band."
This means the source will tell
destination site some information
about the
SourceID, for
example, by email . So
that destination site is able to maintain that table.
Should we consider
to suggest this out-of-band information be in
plain text,
instead of 20 byte
sequence? As it's hard to put that 20-bytes into a config
file
without any
conversion.
Thanks,
-Fred
-----Original Message-----
From:
Mishra, Prateek
Sent: Thursday, April 18, 2002 5:10
PM
To: 'Hal Lockhart'; Chen, Fred;
Subject: RE: [saml-dev] SAML
artifact source id config.
Hal,
The
issue here is simply that the out-of-band message is
a
20-byte sequence (not a string!). That is all. Folks
participating
in the
web browser profile should ensure that their
administration
GUIs
etc. do not assume that the partner source ID is a
string.
It is
an arbitrary 20 byte sequence and may be delivered,
(out of
band) using hex, just for example.
-
prateek
-----Original Message-----
From: Hal Lockhart
[mailto:]
Sent: Thursday, April 18,
2002 5:00 PM
To: 'Chen, Fred';
Subject: RE: [saml-dev] SAML
artifact source id config.
I don't understand this at all. Section 4.1.1.8 (lines
567-570) says:
"SourceID is a 20-byte sequence used by the destination
site to determine source site identity and location. It is assumed that
the destination site will maintain a table of SourceID values as well as
the URL (or address) for the corresponding SAML responder. This
information is communicated between the source and destination sites
out-of-band."
Out of band means not in any SAML message. I don't see
anything to specify here.
When contained in the artifact and sent via URL
encoding, it is base64 encoded.
What am I missing?
Hal
> -----Original Message-----
> From: Chen, Fred [mailto:]
> Sent: Thursday, April 18, 2002 4:31 PM
> To:
> Subject: [saml-dev] SAML artifact source id config.
>
>
> Hi folks,
>
> I am writing some code to support saml browser/artifact
profiling.
> According to
draft-sstc-bindings-model-15, In section
> 4.1.1.6, it says "In
> steps 4
and 5, the destination site, in effect, dereferences
> the one or more
> SAML artifacts
in its possession in order to acquire the SAML
> authentication
> assertion
...."
> I run into a problem that when the
destination site composes
> a config
file
> in its possession. As its partner
sends the 20-byte code,
> which is
typically
> a SHA-1 output with some
non-displayable characters, you must
> have
awared
> that a conversion from byte array
into plain text is needed.
> This may
cause
> some man made error or code
burden/incompatibility on the
> destination
site.
>
> How
about its partner sends the hex string or Base64 encoded
> string of the
>
SourceID for the agreement/configuration purpose.
>
> Please note, this doesn't
affect the artifact format of
> section
4.1.1.8.
>
> Any
thought?
>
>
-Fred
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use
the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
